Feature/lab10

.github/pull_request_template.md

@@ -0,0 +1,17 @@
+## Goal
+
+In short: why this PR?
+
+## Changes
+
+What and why are we changing?
+
+## Testing
+
+How we checked: steps/logic
+
+### Checklist
+
+- [ ]  PR has a clear, specific title
+- [ ]  Updated README as needed
+- [ ]  No secrets and junk/large temporary files

.github/workflows/github-actions-demo.yml

@@ -0,0 +1,35 @@
+name: GitHub Actions Demo
+
+on:
+  push:
+    branches: [ "feature/lab3" ]
+  workflow_dispatch:
+
+jobs:
+  Explore-GitHub-Actions:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Print GitHub context
+        run: |
+          if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
+            echo "🎉 The job was manually triggered using workflow_dispatch"
+          else
+            echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
+          fi
+
+      - name: List files in the repository
+        run: |
+          ls ${{ github.workspace }}
+
+      - name: System Information
+        run: |
+          echo "🖥️ Runner Environment Information:"
+          echo "OS: $(uname -a)"
+          echo "CPU Info:"
+          lscpu
+          echo "Memory Info:"
+          free -h
+          echo "Disk Info:"
+          df -h

gitops-lab/current-state.txt

@@ -0,0 +1,3 @@
+version: 1.0
+app: myapp
+replicas: 3

gitops-lab/desired-state.txt

@@ -0,0 +1,3 @@
+version: 1.0
+app: myapp
+replicas: 3

gitops-lab/health.log

@@ -0,0 +1,25 @@
+Wed Nov 12 13:29:15 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:29:25 MSK 2025 - ❌ CRITICAL: State mismatch detected!
+  Desired MD5: a15a1a4f965ecd8f9e23a33a6b543155
+  Current MD5: 48168ff3ab5ffc0214e81c7e2ee356f5
+Wed Nov 12 13:29:37 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:29:50 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:29:53 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:29:56 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:29:59 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:02 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:05 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:08 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:11 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:14 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:17 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:33 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:36 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:39 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:42 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:45 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:48 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:52 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:55 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:30:58 MSK 2025 - ✅ OK: States synchronized
+Wed Nov 12 13:31:01 MSK 2025 - ✅ OK: States synchronized

gitops-lab/healthcheck.sh

@@ -0,0 +1,13 @@
+#!/bin/bash
+# healthcheck.sh - Monitor GitOps sync health
+
+DESIRED_MD5=$(md5sum desired-state.txt | awk '{print $1}')
+CURRENT_MD5=$(md5sum current-state.txt | awk '{print $1}')
+
+if [ "$DESIRED_MD5" != "$CURRENT_MD5" ]; then
+    echo "$(date) - ❌ CRITICAL: State mismatch detected!" | tee -a health.log
+    echo "  Desired MD5: $DESIRED_MD5" | tee -a health.log
+    echo "  Current MD5: $CURRENT_MD5" | tee -a health.log
+else
+    echo "$(date) - ✅ OK: States synchronized" | tee -a health.log
+fi

gitops-lab/monitor.sh

@@ -0,0 +1,10 @@
+#!/bin/bash
+# monitor.sh - Combined reconciliation and health monitoring
+
+printf "Starting GitOps monitoring...\n"
+for i in {1..10}; do
+    printf "\n--- Check #%d ---\n" "$i"
+    ./healthcheck.sh
+    ./reconcile.sh
+    sleep 3
+done

gitops-lab/reconcile.sh

@@ -0,0 +1,14 @@
+#!/bin/bash
+# reconcile.sh - GitOps reconciliation loop
+
+DESIRED=$(cat desired-state.txt)
+CURRENT=$(cat current-state.txt)
+
+if [ "$DESIRED" != "$CURRENT" ]; then
+    echo "$(date) - ⚠️  DRIFT DETECTED!"
+    echo "Reconciling current state with desired state..."
+    cp desired-state.txt current-state.txt
+    echo "$(date) - ✅ Reconciliation complete"
+else
+    echo "$(date) - ✅ States synchronized"
+fi

labs/submission1.md

@@ -0,0 +1 @@
+Signed commits help to verify that the changes were made by the developer and not someone else. This protects the project from code substitution and increases trust within the team. On GitHub, such commits are marked as Verified, and anyone can verify their authenticity. You can use SSH or GPG keys for signing, SSH is most often used, as it is easier to set up.

labs/submission10.md

@@ -0,0 +1,145 @@
+# Lab 10 Submission — Cloud Computing Fundamentals
+
+## Task 1 — Artifact Registries Research
+
+### Services Overview
+
+**AWS:**
+- **Amazon Elastic Container Registry (ECR):** Private Docker/OCI registry with vulnerability scanning (Amazon Inspector), encryption at rest, IAM integration, cross-region/account replication, and CI/CD hooks.
+- **AWS CodeArtifact:** Managed package repository for Maven, npm, PyPI, NuGet, and Cargo. Integrates with standard package managers and AWS build tools.
+
+**Google Cloud:**
+- **Artifact Registry:** Unified registry for container images and language packages (Maven, npm, Python, Go, etc.). Includes IAM, vulnerability scanning, attestations, and Cloud Build integration.
+
+**Azure:**
+- **Azure Container Registry (ACR):** Private Docker/OCI registry with geo-replication (Premium tier), content trust/signing, Private Link, and ACR Tasks.
+- **Azure Artifacts:** Azure DevOps service for language packages (npm, Maven, NuGet, Python, Cargo, Universal Packages).
+
+### Supported Artifact Types
+
+| Cloud | Service | Containers | Helm | Maven | npm | Python | NuGet | Go | OS Packages | Generic |
+|-------|---------|-----------|------|-------|-----|--------|-------|----|-------------|---------|
+| AWS | ECR | ✅ | ✅ (OCI) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ (OCI) |
+| AWS | CodeArtifact | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ (Cargo) | ❌ | ❌ |
+| GCP | Artifact Registry | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ (apt/yum) | ✅ |
+| Azure | ACR | ✅ | ✅ (OCI) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
+| Azure | Azure Artifacts | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ (Cargo) | ❌ | ✅ (Universal) |
+
+### Key Features
+
+**Security & Compliance:**
+- **ECR:** Image scanning via Inspector, KMS/SSE encryption, IAM policies
+- **Artifact Registry:** Vulnerability scanning and attestations, IAM
+- **ACR:** Image signing/content trust, Defender integrations, private networking
+
+**Networking & Replication:**
+- **ECR:** Cross-region and cross-account replication, VPC endpoints
+- **Artifact Registry:** Regional repositories, Private Service Connect
+- **ACR:** Geo-replication (Premium tier), Private Link
+
+**CI/CD & Ecosystem:**
+- **ECR:** Tight integration with ECS/EKS/CodeBuild/CodePipeline
+- **Artifact Registry:** Cloud Build, Cloud Deploy, GKE
+- **ACR:** AKS, GitHub Actions/Azure Pipelines, ACR Tasks (builds, base-image updates)
+
+### Comparison Table
+
+| Factor | AWS ECR | GCP Artifact Registry | Azure ACR |
+|--------|---------|----------------------|-----------|
+| Artifact formats | Docker/OCI | Docker/OCI + Maven/npm/Python/Go/OS packages | Docker/OCI |
+| Vulnerability scanning | ✅ (Inspector) | ✅ (Artifact Analysis) | ✅ (Defender/partner) |
+| Replication | Cross-region/account | Regional repos | Geo-replication (Premium) |
+| Access control | IAM | IAM | RBAC/AAD |
+| Private networking | VPC endpoints | Private Service Connect | Private Link |
+| CI/CD integration | ECS/EKS/Code* | Cloud Build/Deploy/GKE | AKS/ACR Tasks/Pipelines |
+| Pricing | Storage + egress | Storage + egress | SKU tier + features |
+
+### Analysis: Multi-Cloud Strategy
+
+For a multi-cloud setup, **GCP Artifact Registry** is the most unified option — it covers containers, language packages, and OS packages in one service. If you need everything in one place, it's hard to beat.
+
+For **AWS-centric stacks**, pair **ECR** (images) with **CodeArtifact** (packages) for full coverage and deep AWS integration.
+
+For **Azure-centric stacks** that need geo-replication and private networking, **ACR Premium** makes sense.
+
+**Bottom line:** Choose based on your platform preference and network/replication needs. Keep artifacts OCI-compliant and policies portable to avoid lock-in.
+
+---
+
+## Task 2 — Serverless Computing Platform Research
+
+### Services Overview
+
+**AWS:**
+- **Lambda:** Functions-as-a-Service (FaaS) with rich event ecosystem (S3, SNS, EventBridge, API Gateway). Max runtime **15 minutes**. Cold start mitigation: Provisioned Concurrency, SnapStart (Java).
+
+**Google Cloud:**
+- **Cloud Functions (Gen2) / Cloud Run:** Functions on Cloud Run or direct serverless containers with HTTP/event triggers. Cloud Run allows per-request runtimes up to **60 minutes** and supports minimum instances to keep containers warm.
+
+**Azure:**
+- **Azure Functions:** FaaS with multiple hosting plans. **Consumption** has default timeout up to **10 minutes**; **Premium** reduces cold starts via pre-warmed instances and allows longer runtimes with VNet integration.
+
+### Runtimes and Execution Models
+
+**Lambda:** Multiple managed runtimes (Node.js, Python, Java, .NET, Ruby, Go) or custom container images. Automatic scaling, concurrency controls, wide event sources.
+
+**Cloud Functions/Run:** HTTP and event triggers, Pub/Sub, Eventarc. Min/max instances for scale and cold-start control. Supports Node.js, Python, Go, Java, .NET, PHP, Ruby.
+
+**Azure Functions:** HTTP/queue/timer/event triggers. Premium keeps instances pre-warmed. Deep Azure integrations. Supports JavaScript/TypeScript, C#/F#, Python, Java, PowerShell, custom handlers.
+
+### Performance Characteristics
+
+**Cold starts:**
+- Lambda: Provisioned Concurrency and SnapStart reduce startup latency
+- Cloud Run: Min instances keep containers hot
+- Azure Functions Premium: Pre-warmed workers
+
+**Throughput & concurrency:** All three provide automatic scaling with per-platform concurrency and quota controls.
+
+**Observability:** CloudWatch (AWS), Cloud Logging/Trace (GCP), Application Insights (Azure).
+
+### Limits and Timeouts
+
+| Platform | Max Duration | Cold-Start Mitigation |
+|----------|--------------|----------------------|
+| AWS Lambda | 15 minutes | Provisioned Concurrency, SnapStart (Java) |
+| GCP Cloud Run | 60 minutes | Min instances |
+| GCP Cloud Functions (Gen2) | Inherits Cloud Run (60 min) | Min instances |
+| Azure Functions | 10 min (Consumption), longer on Premium | Pre-warmed instances (Premium) |
+
+### Comparison Table
+
+| Factor | AWS Lambda | GCP Cloud Functions / Cloud Run | Azure Functions |
+|--------|------------|--------------------------------|-----------------|
+| Model | FaaS | FaaS / serverless containers | FaaS |
+| Max duration | 15 min | 60 min (Cloud Run HTTP) | 10 min (Consumption), longer in Premium |
+| Cold start mitigation | Provisioned Concurrency, SnapStart | Min instances (Cloud Run) | Pre-warmed instances (Premium) |
+| Triggers | Broad AWS events + HTTP | HTTP, Pub/Sub, Eventarc | HTTP, Timer, Queues, Event Hub |
+| Networking | VPC integration | VPC/serverless VPC access | VNet integration |
+| Pricing | Requests + GB-s + optional provisioned | Requests + time/CPU/mem | Requests + time; Premium warm cost |
+
+### Analysis: Best Fit for REST API Backend
+
+For **low latency, AWS-native** setups: **Lambda with Provisioned Concurrency** provides predictable startup at extra cost.
+
+For **containerized HTTP with more control**: **Cloud Run** offers standard containers, long HTTP timeouts (60 min), and min instances to keep things warm. Best choice if you want flexibility.
+
+For **Azure-native with stable latency**: **Functions on Premium plan** for pre-warmed workers and VNet integration.
+
+I'd lean toward **Cloud Run** for a REST API — it accepts standard containers or functions, allows high concurrency per instance, has the longest HTTP timeout, and lets you keep a warm instance running to smooth out latency.
+
+### Reflection: Pros & Cons of Serverless
+
+**Pros:**
+- No server management
+- Automatic scaling
+- Pay-for-use
+- Scale-to-zero
+
+**Cons:**
+- Cold starts can cause delays
+- Per-platform limits and quotas
+- Requires tuning for latency
+- Possible vendor lock-in with proprietary triggers and monitoring
+
+The trade-off is clear: you get operational simplicity and cost efficiency, but you lose some control and have to work around platform-specific limitations.