Cloud Computing Skill Lab

• Skill Lab rules, VTU guidelines, evaluation scheme and certification process.
• Linux essentials for cloud work: shell, files, permissions, package management (apt), systemd services, SSH, text editors (nano/vim) and curl.
• Issue of your personal CIT-Cloud credentials: student ID, project access token, port range, S3 access keys and Git account.

• Evolution from client-server, grid and utility computing to cloud; the NIST definition and five essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service).
• Service models: IaaS, PaaS, SaaS and newer models – CaaS, FaaS/serverless, STaaS and AI-as-a-Service; the shared responsibility model.
• Deployment models: public, private, hybrid, community and multi-cloud; when a private cloud is the right choice.
• Virtualisation: Type-1 vs Type-2 hypervisors, KVM, full vs para-virtualisation, VMs vs containers, multi-tenancy.

• Building blocks of any cloud: compute, storage (block, file, object), networking (virtual networks, NAT, security groups, load balancers), identity and quotas, metering and monitoring.
• Private-cloud platforms: OpenStack, Apache CloudStack, LXD/Incus, Proxmox; a guided tour of the CIT-Cloud architecture.
• Cloud-native concepts: microservices, containers, Kubernetes, DevOps, CI/CD, Infrastructure-as-Code and observability.
• Cloud economics (CapEx vs OpEx), security and compliance, careers and certifications.
• Live demo: launching a VM in seconds, using a SaaS application, and calling a private AI (LLM) API.

Aim: Access the private cloud through its self-service portal and CLI using key-based authentication, and understand projects, quotas and multi-tenancy.

1. Generate an SSH key pair (ssh-keygen -t ed25519) on the lab PC.
2. Add CIT-Cloud as a remote using your issued access token and switch to it.
3. Log in to the cloud's web portal using the generated client certificate.
4. Inspect your project quota and usage, and list the available OS images.
5. Try to access another student's project and observe that access is denied (tenant isolation).

Outcome: Portal login, project limits and an access-denied message, with an explanation of how quotas and isolation work.
Tools: LXD UI, lxc, SSH  |  Industry equivalent: AWS Console, IAM, key pairs

Aim: Provision compute instances on demand, automate their first-boot configuration and manage their lifecycle.

1. Launch a KVM virtual machine with defined CPU and memory limits.
2. Launch a system container and compare boot time and memory footprint with the VM.
3. Write a cloud-init user-data file that creates a user, installs packages and adds your SSH key.
4. Perform lifecycle operations: start, stop, restart, exec, console, info, delete.
5. Resize an instance (vertical scaling) and verify with nproc and free -h.

Outcome: A running VM and container, a VM-vs-container comparison and automated configuration logs.
Tools: LXD, KVM, cloud-init  |  Industry equivalent: Amazon EC2 + user data

Aim: Use persistent block storage independent of instances, and protect and reuse instance state.

1. Create a 5 GiB volume, attach it to the VM, partition, format and mount it, and write data.
2. Detach the volume, attach it to another instance and verify the data persists.
3. Snapshot an instance, deliberately break a configuration, then restore from the snapshot.
4. Publish an instance as a custom image and launch a new instance from it.
5. Export an instance backup for use in Program 10.

Outcome: Volume visible across instances, successful snapshot restore and a reusable custom image.
Tools: LXD, ZFS  |  Industry equivalent: Amazon EBS, snapshots, AMI

Aim: Understand cloud virtual networks, private IP addressing, NAT, DNS and firewall rules (security groups).

1. Inspect instance networking: IP addresses, routes, DHCP lease and internal DNS; ping between instances.
2. Assign a static private address to the VM.
3. Install nginx and configure network ACLs and ufw to allow only SSH and HTTP.
4. Access your web server and SSH from the lab PC through your personal port forwards.
5. Show that a blocked port is unreachable and explain the traffic path (lab PC → host → NAT → VM).

Outcome: A network diagram of your environment, working HTTP/SSH access and firewall rules.
Tools: Linux bridge, ACL, ufw, proxy devices  |  Industry equivalent: AWS VPC, Security Groups

Aim: Deploy an application on IaaS, create a reusable golden image and scale out horizontally behind a load balancer.

1. Deploy a small Python Flask or PHP web application as a systemd service.
2. Publish the configured instance as a golden image and launch two clones from it.
3. Configure HAProxy (or nginx) as a round-robin load balancer in front of the clones.
4. Stop one clone and observe that the service stays available (health checks and fault tolerance).

Outcome: Responses alternating between clones; availability maintained with one backend down.
Tools: nginx, HAProxy, LXD  |  Industry equivalent: EC2 + Elastic Load Balancer, AMI

Aim: Package an application as a portable container image and distribute it through a private registry.

1. Run basic Docker containers (run, ps, logs, exec, stop, rm).
2. Write a Dockerfile for a Flask application; build, tag and run it with port mapping and environment variables.
3. Apply image best practices: slim base image, .dockerignore and multi-stage builds; compare image sizes.
4. Push the image to the private registry and pull it on another instance.

Outcome: Image listed in the private registry and the application running from the pulled image.
Tools: Docker, Gitea registry  |  Industry equivalent: Amazon ECR, Azure Container Registry

Aim: Define and run a multi-tier application declaratively.

1. Write a compose.yaml for a web app + Redis (visit counter) + PostgreSQL with named volumes and a private network.
2. Use environment files, health checks and dependencies; bring the stack up and down.
3. Scale the web tier to three replicas behind an nginx container.
4. Demonstrate data persistence across container re-creation.

Outcome: A running multi-tier stack with persistent data and a scaled web tier.
Tools: Docker Compose, Redis, PostgreSQL  |  Industry equivalent: Amazon ECS task definitions

Aim: Deploy and manage containerised workloads on a Kubernetes cluster.

1. Install single-node K3s inside your VM; explore nodes, namespaces and system pods with kubectl.
2. Deploy your Program 6 image as a Deployment with 3 replicas and expose it as a Service.
3. Use a ConfigMap and a Secret; add liveness and readiness probes.
4. Delete a pod and observe self-healing; perform a rolling update and a rollback.

Outcome: Deployment manifests and evidence of self-healing, rolling update and rollback.
Tools: K3s, kubectl  |  Industry equivalent: Amazon EKS, Azure AKS, Google GKE

Aim: Demonstrate elasticity — automatically adding and removing capacity as load changes.

1. Set CPU requests and limits; verify metrics with kubectl top.
2. Create a Horizontal Pod Autoscaler (min 1, max 6 replicas, 50% CPU target).
3. Generate load and observe scale-out; stop the load and observe scale-in.
4. Expose the application through an Ingress with host/path-based routing.

Outcome: A graph of replica count versus time under load and working Ingress routes.
Tools: HPA, metrics-server, Traefik, hey  |  Industry equivalent: AWS Auto Scaling, Application Load Balancer

Aim: Use S3-compatible object storage programmatically — the most widely used cloud storage interface.

1. Configure the AWS CLI with your issued access keys and the CIT-Cloud S3 endpoint.
2. Create a bucket; upload, list, download, copy and delete objects; use prefixes (folders).
3. Generate a pre-signed URL to share a file for a limited time.
4. Write a Python (boto3) script to upload your Program 3 backup and list bucket contents.
5. Host a static website from a bucket and open it in a browser.

Outcome: Bucket listing, a working pre-signed URL and boto3 script output.
Tools: SeaweedFS, AWS CLI, boto3  |  Industry equivalent: Amazon S3, Azure Blob Storage

Aim: Provision and configure cloud infrastructure repeatably from code instead of manual clicks.

1. Write an OpenTofu configuration that creates two instances with a profile and resource limits.
2. Run init / plan / apply; inspect the state; change a parameter and re-apply; destroy and re-create.
3. Write an Ansible inventory and playbook to install and configure nginx with a templated page on both instances.
4. Re-run the playbook to demonstrate idempotency.

Outcome: IaC code in Git, plan/apply output and identically configured servers.
Tools: OpenTofu, Ansible  |  Industry equivalent: Terraform, AWS CloudFormation

Aim: Automate the build and deployment of an application and observe the health of cloud resources.

1. Push your code to a Git repository and write a pipeline that builds the Docker image and pushes it to the registry.
2. Extend the pipeline to deploy the new image to your Kubernetes cluster on every commit.
3. Collect VM metrics (CPU, memory, disk, network) with Prometheus and view them in Grafana dashboards.
4. Create a Grafana alert (e.g. CPU > 80% for 2 minutes) and trigger it with a load test.

Outcome: A successful pipeline run, automatic application updates, and a dashboard with a working alert.
Tools: Gitea Actions, Prometheus, Grafana  |  Industry equivalent: GitHub Actions, AWS CodePipeline, Amazon CloudWatch