{"id":15118574,"url":"https://github.com/greyhats13/fta_users","last_synced_at":"2026-01-18T22:34:13.966Z","repository":{"id":257717760,"uuid":"859093055","full_name":"greyhats13/fta_users","owner":"greyhats13","description":null,"archived":false,"fork":false,"pushed_at":"2024-09-19T08:52:14.000Z","size":60,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2024-09-27T01:47:17.614Z","etag":null,"topics":["docker","gcp","kubernetes","nodejs","postgresql","service"],"latest_commit_sha":null,"homepage":"false","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/greyhats13.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-09-18T04:26:06.000Z","updated_at":"2024-09-19T08:51:12.000Z","dependencies_parsed_at":"2024-09-18T08:28:06.572Z","dependency_job_id":"06e1f3cd-3d8f-4a8a-9c1c-594fd775f81c","html_url":"https://github.com/greyhats13/fta_users","commit_stats":null,"previous_names":["greyhats13/fta_users"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/greyhats13%2Ffta_users","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/greyhats13%2Ffta_users/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/greyhats13%2Ffta_users/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/greyhats13%2Ffta_users/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/greyhats13","download_url":"https://codeload.github.com/greyhats13/fta_users/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":219868582,"owners_count":16555778,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["docker","gcp","kubernetes","nodejs","postgresql","service"],"created_at":"2024-09-26T01:47:17.941Z","updated_at":"2024-10-09T16:06:03.594Z","avatar_url":"https://github.com/greyhats13.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# DevOps/SRE Engineer Take Home Test\n\nYou need to:\n1. Clone this repo, then update based on the **Tasks** section below\n2. Create a new repo for Infrastructure as Code. Terraform is prefered. But feel free to use any similar tools.\n3. Deploy to any environtment. You may use localhost and exposed through ngrok.io. You may also use public cloud, like GCP with free trial account.\n4. Once #1, #2, #3 are ready, please inform us the repo URLs (#1 and #2) and application URL (#3).\n\n---\n# Quick Start\n\nThis repo contains source code for simple express application that reads data from Postgres database.\n\n## Prerequisites\n- [NodeJS LTS/fermium](https://nodejs.org/en/about/releases/)\n- [Postgres](https://www.postgresql.org/)\n- Docker\n- [Gitlab Runner](https://docs.gitlab.com/runner/install/)\n- [Terraform](https://www.terraform.io/) - or something similar for IaC, e.g., Vagrant, Ansible\n\n## How to run this application code\n1. Create `.env` file in the root folder, populate from `.env.example`\n1. Update `.env` file based on your DB configuration\n1. Run `npm i`\n1. Migrate schema: `npm run migrate`\n1. Migrate data: `npm run seed`\n1. Run app `npm start` \n1. Open it on `localhost:3000`\n\n## API Specification\n| API Route | Description |\n|---|---|\n| {base_url}/health | Return OK when the DB is connected and API is up and running |\n| {base_url}/users | Return all data in `users` table, populated during the migration |\n\n\n## DB Connection\nThe DB connection is maintained as environment variables.\n```\nusername='username'\npassword='password'\ndatabase='database_name'\nhost='127.0.0.1'\nport='5432'\n```\n\n---\n\n# Tasks\nAs a DevOps engineer, you are requested by the team to:\n1. Containerize the application\n1. Create kubernetes deployment\n1. Build CI/CD pipeline\n1. Deploy the application to publicly accessed env\n1. Condify all the infrastructures needed as a code (IaC)\n\n## Design\n\n```\n┌───────────────┐\n│               │\n│  Express App  │\n│               │\n└──────┬────────┘\n       │\n       ▼\n┌───────────────┐\n│  Postgres DB  │\n│               │\n└───────────────┘\n```\n\n### Express App\nYou need to deploy this application as a container in a Kubernetes cluster. For the cluster, you may use managed platform, like GKE, AKS, EKS. Or, you may deploy it in your local k8s cluster with Minikube / k3s.\n\n### Postgres DB\nYou need to provision Postgres DB server. You may use a stateful container inside of K8s cluser. Or you may use managed Postgres server like GCP's SQL Cloud.\n\n## Environments\nYou need to provide 2 environment in your configuration files: development and production. For the databases, you may decide how you do the separation, e.g., same DB but different schema, or completly different DB servers.\n\n## Task 1 - Containerize the web app\nYou need to create a `Dockerfile` file to containerize this application. When spawning a new container, the app should run locally and migrate schema and data to the DB.\nPlease refer the code here: https://github.com/greyhats13/fta_users/blob/main/Dockerfile\n\n## Task 2 - Create kubernetes deployment\nYou also need to create [kubernetes deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) config files for each of the environments.\n\n\n**Plus**\n\nUse file templating, like helmChart, or jsonnet-based tools like tanka, qbec, or kubecfg\n\n## Task 3 - Build CI/CD pipelines\nYou need to create `.gitlab-ci.yml` file with the following requirements: \n\n| Environment | Stages | Trigger | Action |\n|---|---|---|---|\n| Development | Build | Merge to dev | Build Docker image with latest tag |\n|  | Deploy | Automatic | Create deployment with 1 replica. Namespace: `dev` |\n| Production | Build | Create a new tag | Build Docker image with version tag |\n|  | Deploy | Manual | Create deployment with 2 replicas. Namespace: `prod` |\n\n**Hint**\n\nYou may use local [gitlab runner](https://docs.gitlab.com/runner/install/) to validate and run your `.gitlab-ci.yml` file locally.\n\n**Plus**\n\nStore configuration in a secret manager, e.g., [k8s secrets](https://kubernetes.io/docs/concepts/configuration/secret/), GCP secret manager, etc.\n\n##  Task 4 - Deploy the application to publicly accessed env\nOnce done, you need to deploy the application and database into a publicly accessed environment. This is only for the production environment. If you are using localhost, make sure you activate [ngrok.io](ngrok.io). If you use public cloud, make sure it has public IP address / DNS associated.\n\n## Task 5 - Codify all infrastrctures as code (IaC)\nWe would definitly consider as a big plus if you can provide infrastructure as a code to provision above building blocks. For this, you may use Terraform, Vagrant, or Ansible. Please provide a new repo to store IaC configuration files.\n\n# Technical Task Solution\n\nThis README provides a comprehensive solution to the technical tasks outlined for containerizing a web application, setting up Kubernetes deployments, building CI/CD pipelines, deploying to a publicly accessible environment, and codifying infrastructure as code (IaC). Each task is detailed with a focus on concepts and system design, referencing relevant code repositories and configurations.\n\n# ANSWER\n\n## Task 1 - Containerize the Web App\n\n### Overview\n\nContainerizing the web application ensures consistency across different environments, simplifies deployment, and enhances scalability. The process involves creating a `Dockerfile` that defines the application's container image, handling dependencies, and setting up the runtime environment.\n\n### Dockerfile Design\n\nThe `Dockerfile` provided utilizes a multi-stage build to optimize the final image size and ensure a clean separation between the build and production environments.\n\n```Dockerfile\n# Stage 1: Builder\nFROM node:alpine3.14 AS builder\n\n# Set the working directory\nWORKDIR /app\n\n# Copy package.json and package-lock.json (if available)\nCOPY package*.json ./\n\n# Install dependencies and clean cache\nRUN npm ci --only=production \u0026\u0026 npm cache clean --force\n\n# Copy the entire application code\nCOPY . .\n\n# Stage 2: Production\nFROM node:alpine3.14\n\n# Set the working directory\nWORKDIR /app\n\n# Copy application files and node_modules from the builder stage\nCOPY --from=builder /app . \n\n# Create a non-root group and user, and set ownership\nRUN addgroup -S appgroup \u0026\u0026 adduser -S appuser -G appgroup \u0026\u0026 \\\n    chown -R appuser:appgroup /app\n\n# Switch to the non-root user\nUSER appuser\n\n# Expose the application port\nEXPOSE 3000\n\n# Set environment variables\nENV NODE_ENV=production\n\n# Define the entrypoint to run migrations, seed data, and start the application\nENTRYPOINT [\"sh\", \"-c\", \"npm run migrate \u0026\u0026 npm run seed \u0026\u0026 npm start\"]\n```\n\n### Explanation\n\n1. **Multi-Stage Build**:\n   - **Builder Stage**: Utilizes the `node:alpine3.14` image to install dependencies and prepare the application.\n   - **Production Stage**: Also based on `node:alpine3.14`, it copies the built application from the builder stage, ensuring a lightweight final image.\n\n2. **Working Directory**:\n   - Set to `/app` to maintain consistency and organization within the container.\n\n3. **Dependency Management**:\n   - Copies `package.json` and `package-lock.json` to leverage Docker layer caching, optimizing build times.\n   - Uses `npm ci --only=production` to install only production dependencies, reducing the image size.\n\n4. **Application Code**:\n   - The entire application code is copied into the container, ensuring all necessary files are present.\n\n5. **Security**:\n   - A non-root user (`appuser`) and group (`appgroup`) are created to run the application, enhancing security by minimizing permissions.\n\n6. **Port Exposure**:\n   - Exposes port `3000` to allow external access to the application.\n\n7. **Environment Variables**:\n   - Sets `NODE_ENV` to `production` to optimize the application for a production environment.\n\n8. **Entrypoint**:\n   - Executes database migrations, seeds data, and starts the application upon container startup, ensuring the application is ready to handle requests immediately.\n\n### Repository Reference\n\nThe complete `Dockerfile` can be found in the [fta_users repository](https://github.com/greyhats13/fta_users/blob/main/Dockerfile).\n\n---\n\n## Task 2 - Create Kubernetes Deployment\n\n### Overview\n\nDeploying the containerized application to Kubernetes ensures scalability, reliability, and efficient resource management. Kubernetes Deployments manage the desired state, handle scaling, and provide mechanisms for rolling updates.\n\n### Deployment Strategy\n\nTo manage Kubernetes deployments across different environments (development, staging, production), Helm charts are utilized. Helm simplifies the deployment process by templating Kubernetes manifests, allowing for environment-specific configurations.\n\n### Implementation\n\n- **Helm Charts**: Defined within the `fta_gitops` repository, Helm charts are used to parameterize deployment configurations for each environment.\n  \n- **Environment-Specific Configurations**:\n  - **Incubator (Development)**: Utilizes a separate namespace (`dev`) with configurations tailored for development, such as a single replica for cost efficiency.\n  - **Test (Staging)**: Configured for staging environments to mimic production settings closely, enabling thorough testing before production deployments.\n  - **Stable (Production)**: Optimized for high availability and performance, typically with multiple replicas and robust resource allocations.\n\n### Repository Reference\n\nKubernetes Deployment configurations using Helm charts are maintained in the [fta_gitops repository](https://github.com/greyhats13/fta_gitop). This repository contains templates and values files for each environment:\n\n- **Incubator (Dev)**: Configurations for the development environment.\n- **Test (Staging)**: Configurations for the staging environment.\n- **Stable (Production)**: Configurations for the production environment.\n\n### Design Considerations\n\n1. **Scalability**:\n   - Helm charts allow easy scaling of replicas based on environment needs.\n  \n2. **Environment Isolation**:\n   - Separate namespaces for each environment ensure isolation and prevent cross-environment interference.\n\n3. **Configuration Management**:\n   - Centralized management of configurations through Helm promotes consistency and simplifies updates.\n\n4. **Version Control**:\n   - Helm charts are versioned alongside application code, ensuring synchronized deployments.\n\n---\n\n## Task 3 - Build CI/CD Pipelines\n\n### Overview\n\nA robust CI/CD pipeline automates the process of building, testing, and deploying applications, ensuring rapid and reliable delivery. The pipeline handles different stages and environments, integrates with version control, and leverages secret management for security.\n\n### CI/CD Pipeline Design\n\nThe pipeline is implemented using GitHub Actions, defined in the `.github/workflows/github-ci.yml` file. It encompasses stages for building Docker images, deploying to Kubernetes, and managing environment-specific actions.\n\n### Pipeline Configuration\n\n```yml\nname: CI/CD for FTA Users\non:\n  push:\n    branches:\n      - main\n      - dev\n    tags:\n      - 'v*'\njobs:\n  docker:\n    environment: fta_users\n    name: Docker\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout code\n        uses: actions/checkout@v2\n\n      - name: Set up Docker Buildx\n        uses: docker/setup-buildx-action@v1\n\n      - name: Login to Docker Hub\n        uses: docker/login-action@v1\n        with:\n          username: ${{ secrets.DOCKER_USERNAME }}\n          password: ${{ secrets.DOCKER_PASSWORD }}\n\n      - name: Set Image Tag\n        run: |\n          if [[ $GITHUB_REF == refs/heads/dev ]]; then\n            echo \"IMAGE_TAG_LATEST=alpha-latest\" \u003e\u003e $GITHUB_ENV\n            echo \"IMAGE_TAG_SHA=alpha-$(echo ${{ github.sha }} | tail -c 9)\" \u003e\u003e $GITHUB_ENV\n            echo \"CHART_PATH=${{ vars.GITOPS_PATH_DEV }}\" \u003e\u003e $GITHUB_ENV\n          elif [[ $GITHUB_REF == refs/heads/main ]]; then\n            echo \"IMAGE_TAG_LATEST=beta-latest\" \u003e\u003e $GITHUB_ENV\n            echo \"IMAGE_TAG_SHA=beta-$(echo ${{ github.sha }} | tail -c 9)\" \u003e\u003e $GITHUB_ENV\n            echo \"CHART_PATH=${{ vars.GITOPS_PATH_STG }}\" \u003e\u003e $GITHUB_ENV\n          elif [[ $GITHUB_REF == refs/tags/* ]]; then\n            echo \"IMAGE_TAG_LATEST=latest\" \u003e\u003e $GITHUB_ENV\n            echo \"IMAGE_TAG_SHA=${GITHUB_REF#refs/tags/}\" \u003e\u003e $GITHUB_ENV\n            echo \"CHART_PATH=${{ vars.GITOPS_PATH_PRD }}\" \u003e\u003e $GITHUB_ENV\n          else\n            echo \"IMAGE_TAG=no_build\" \u003e\u003e $GITHUB_ENV\n            echo \"CHART_PATH=no_build\" \u003e\u003e $GITHUB_ENV\n            echo \"IMAGE_TAG_SHA=no_build\" \u003e\u003e $GITHUB_ENV\n          fi\n\n      - name: Build, Tag, and Push\n        if: (env.IMAGE_TAG_SHA != 'no_build' || env.IMAGE_TAG_LATEST != 'no_build') \u0026\u0026 !startsWith(env.IMAGE_TAG_SHA, 'v')\n        id: docker_build\n        uses: docker/build-push-action@v2\n        with:\n          context: .\n          push: true\n          tags: ${{ vars.DOCKER_REPOSITORY_URI }}:${{ env.IMAGE_TAG_SHA }}, ${{ vars.DOCKER_REPOSITORY_URI }}:${{ env.IMAGE_TAG_LATEST }}\n          platforms: linux/amd64\n\n      - name: Retag and Push for Release\n        if: startsWith(env.IMAGE_TAG, 'v')\n        run: |\n          docker pull ${{ vars.DOCKER_REPOSITORY_URI }}:beta-latest\n          docker tag ${{ vars.DOCKER_REPOSITORY_URI }}:beta-latest ${{ vars.DOCKER_REPOSITORY_URI }}:${{ env.IMAGE_TAG_SHA }}\n          docker tag ${{ vars.DOCKER_REPOSITORY_URI }}:beta-latest ${{ vars.DOCKER_REPOSITORY_URI }}:${{ env.IMAGE_TAG_LATEST }}\n          docker push ${{ vars.DOCKER_REPOSITORY_URI }}:${{ env.IMAGE_TAG_SHA }}\n          docker push ${{ vars.DOCKER_REPOSITORY_URI }}:${{ env.IMAGE_TAG_LATEST }}\n\n      - name: Update Helm Chart\n        if: env.CHART_PATH != 'no_build'\n        run: |\n          eval \"$(ssh-agent -s)\"\n          echo \"${{ secrets.GITOPS_SSH_PRIVATE_KEY }}\" \u003e id_rsa\n          chmod 400 id_rsa\n          ssh-add id_rsa\n          ssh-add -l\n          git clone ${{ vars.REPO_GITOPS_SSH }}\n          cd ${{ vars.GITOPS_REPO_NAME }}/${{ env.CHART_PATH }}\n          sed -i \"s|repository: .*|repository: ${{ vars.DOCKER_REPOSITORY_URI }}|\" values.yaml;\n          sed -i \"s/appVersion: \\\".*\\\"/appVersion: \\\"${{ env.IMAGE_TAG_SHA }}\\\"/\" Chart.yaml\n          git add values.yaml Chart.yaml\n          git config --global user.email \"imam.arief.rhmn@gmail.com\"\n          git config --global user.name \"greyhats13\"\n          git commit -m \"Update image tag to $TAG_SUFFIX-${{ github.sha }}\"\n          git push origin main\n```\n\n### Pipeline Stages\n\n| Environment | Stages | Trigger | Action |\n|-------------|--------|---------|--------|\n| **Development** | Build | Merge to `dev` branch | Build Docker image with `alpha-latest` and `alpha-\u003csha\u003e` tags |\n|  | Deploy | Automatic | Deploy to `dev` namespace with 1 replica |\n| **Production** | Build | Create a new tag (e.g., `v1.0.0`) | Build Docker image with `latest` and version-specific tags |\n|  | Deploy | Manual | Deploy to `prod` namespace with 2 replicas |\n\n### Tagging Strategy\n\n- **Development Branch (`dev`)**:\n  - Tags: `alpha-latest` and `alpha-\u003cshort-sha\u003e`\n  - Purpose: Facilitates continuous integration with frequent updates.\n\n- **Main Branch (`main`)**:\n  - Tags: `beta-latest` and `beta-\u003cshort-sha\u003e`\n  - Purpose: Prepares for staging deployments with more stable builds.\n\n- **Production Tags (`v*`)**:\n  - Tags: `latest` and version-specific (e.g., `v1.0.0`)\n  - Purpose: Ensures reproducible and traceable releases.\n\n### GitOps Deployment with ArgoCD and Vault\n\nTo securely manage secrets during deployment, ArgoCD is integrated with the Vault plugin to inject Kubernetes secret placeholders from Google Secret Manager. This approach ensures that sensitive information is not exposed in the GitOps repository.\n\n1. **ArgoCD Configuration**:\n   - Utilizes the Vault plugin to retrieve secrets from Google Secret Manager.\n   - Injects secrets into Kubernetes manifests during the synchronization process.\n\n2. **Secret Management**:\n   - Secrets are stored securely in Google Secret Manager.\n   - Access is controlled via IAM roles, ensuring only authorized components can retrieve secrets.\n\n3. **Deployment Workflow**:\n   - When ArgoCD syncs the GitOps repository, it triggers the Vault plugin.\n   - The plugin fetches the required secrets and injects them into the Kubernetes manifests.\n   - The application is deployed with the necessary secrets without exposing them in the repository.\n\n### Repository Reference\n\nThe GitHub Actions workflow is located in the [fta_users repository](https://github.com/greyhats13/fta_users/blob/main/.github/workflows/github-ci.yml), showcasing the CI/CD pipeline implementation.\n\n### Design Considerations\n\n1. **Automation**:\n   - Automates the build and deployment processes, reducing manual intervention and potential errors.\n\n2. **Security**:\n   - Integrates secret management to handle sensitive information securely.\n   - Utilizes non-root users in Docker containers to minimize security risks.\n\n3. **Scalability**:\n   - Supports multiple environments with tailored configurations, enabling seamless scaling and environment-specific optimizations.\n\n4. **Version Control**:\n   - Maintains versioned Docker images, ensuring traceability and the ability to roll back if necessary.\n\n---\n\n## Task 4 - Deploy the Application to Publicly Accessed Environment\n\n### Overview\n\nDeploying the application to a publicly accessible environment involves configuring network access, ensuring security, and managing database connectivity. The deployment strategy leverages Kubernetes ingress controllers and managed database services to achieve these objectives.\n\n### Deployment Strategy\n\n1. **Ingress Configuration**:\n   - **Nginx Ingress Controller**: Utilized to expose the application to the internet, managing HTTP and HTTPS traffic, and providing features like load balancing and SSL termination.\n\n2. **Database Accessibility**:\n   - **CloudSQL Instance**: Configured as a public instance, allowing access from Google Kubernetes Engine (GKE) by whitelisting the NAT IP.\n   - **Service Account**: The application is assigned a service account with the `cloudsql.client` role, enabling secure and authenticated access to the database.\n\n### Implementation Details\n\n- **Nginx Ingress Controller**:\n  - **Configuration**: Defined within the Helm charts in the `fta_gitops` repository, specifying rules for routing traffic to the application service.\n  - **SSL/TLS**: Configured with CertManager to handle SSL certificates, ensuring secure communication.\n\n- **CloudSQL Configuration**:\n  - **Public IP Access**: The CloudSQL instance is assigned a public IP, with access restricted to the GKE cluster's NAT IP through firewall rules.\n  - **Authentication**: The application utilizes a Google Service Account with the necessary permissions to connect to CloudSQL securely.\n\n### Design Considerations\n\n1. **Security**:\n   - **Network Policies**: Implemented to restrict access to the database, allowing only authorized sources.\n   - **SSL/TLS Encryption**: Ensures data in transit is encrypted, protecting against eavesdropping and man-in-the-middle attacks.\n\n2. **Scalability and Reliability**:\n   - **Load Balancing**: Managed by the Nginx Ingress Controller, distributing traffic efficiently across application replicas.\n   - **High Availability**: Configured through multiple replicas and failover mechanisms in CloudSQL.\n\n3. **Monitoring and Logging**:\n   - Integrated with monitoring tools to track application performance and detect anomalies.\n\n### Repository Reference\n\nDeployment configurations are managed within the [fta_gitops repository](https://github.com/greyhats13/fta_gitop), including Helm charts for the Nginx Ingress Controller and CloudSQL setup.\n\n### Design Highlights\n\n- **Public Accessibility**:\n  - The application is accessible via a DNS name associated with the Nginx Ingress Controller, ensuring users can reach the service globally.\n\n- **Database Security**:\n  - By whitelisting the NAT IP and using service accounts, the database remains secure while being accessible to the application.\n\n- **Infrastructure as Code**:\n  - All configurations are codified using Helm charts, enabling reproducible and version-controlled deployments.\n\n---\n\n## Task 5 - Codify All Infrastructures as Code (IaC)\n\n### Overview\n\nCodifying infrastructure as code (IaC) ensures that infrastructure provisioning is automated, consistent, and version-controlled. Utilizing tools like Terraform, the infrastructure required for the application is defined declaratively, enabling easy management and scalability.\n\n### IaC Implementation\n\nThe IaC configurations are maintained in the [fta_iac repository](https://github.com/greyhats13/fta_iac), utilizing Terraform to provision and manage infrastructure components on Google Cloud Platform (GCP).\n\n### Provisioned Components\n\n1. **Cloud Deployment**:\n   - **Virtual Private Cloud (VPC)**: Defines the network topology, including subnets, firewall rules, and routing.\n   - **Google Kubernetes Engine (GKE)**: Manages the Kubernetes cluster, handling container orchestration, scaling, and networking.\n   - **CloudSQL Instance**: Provides a managed relational database service, configured as a public instance with secure access controls.\n   - **Key Management Service (KMS)**: Manages encryption keys for securing sensitive data.\n   - **Secret Manager**: Stores and manages secrets, ensuring secure access and distribution.\n   - **Addons**:\n     - **ExternalDNS**: Automates DNS record management based on Kubernetes resources.\n     - **CertManager**: Manages SSL/TLS certificates, automating issuance and renewal.\n     - **Nginx Ingress Controller**: Handles ingress traffic, providing load balancing and SSL termination.\n     - **ArgoCD**: Facilitates GitOps-based continuous delivery, managing application deployments from Git repositories.\n\n2. **Service Deployment**:\n   - **GitHub Repository**: Hosts the application code and IaC configurations, integrating with CI/CD pipelines for automated deployments.\n   - **Secret Manager for Application**: Stores application secrets, injected securely into Kubernetes deployments.\n   - **Google Service Account**: Assigned to the application with the `cloudsql.client` role, enabling authenticated access to CloudSQL.\n   - **Artifact Registry**: Stores Docker images, facilitating efficient image management and distribution.\n   - **ArgoCD Application for fta-users**: Manages the deployment lifecycle of the `fta-users` application, ensuring desired state synchronization.\n\n### Repository Reference\n\nAll IaC configurations are available in the [fta_iac repository](https://github.com/greyhats13/fta_iac), structured to provision and manage the entire infrastructure stack.\n\n### Infrastructure Components Details\n\n- **VPC**:\n  - **Subnet Configuration**: Defines CIDR blocks, ensuring network segmentation and isolation.\n  - **Firewall Rules**: Specifies ingress and egress rules, controlling traffic flow and enhancing security.\n\n- **GKE Cluster**:\n  - **Node Pools**: Configured with appropriate machine types and scaling policies to handle application workloads.\n  - **Networking**: Integrated with the VPC, enabling secure communication between services.\n\n- **CloudSQL Instance**:\n  - **Instance Configuration**: Specifies database version, machine type, storage capacity, and access controls.\n  - **Connectivity**: Configured for public access with IP whitelisting, ensuring secure connections from GKE.\n\n- **KMS and Secret Manager**:\n  - **Key Management**: Defines encryption keys and access policies, ensuring data is encrypted at rest.\n  - **Secret Storage**: Manages sensitive information like database credentials and API keys, accessible only by authorized services.\n\n- **Addons Integration**:\n  - **ExternalDNS**: Automates DNS management, reducing manual intervention and ensuring consistency.\n  - **CertManager**: Handles certificate lifecycle, enabling HTTPS for secure communication.\n  - **Nginx Ingress Controller**: Manages incoming traffic, providing load balancing and routing.\n  - **ArgoCD**: Implements GitOps principles, automating application deployments based on Git repository states.\n\n### Design Considerations\n\n1. **Modularity**:\n   - Infrastructure components are modularized, allowing for easy updates and maintenance.\n\n2. **Scalability**:\n   - The infrastructure is designed to scale horizontally, handling increasing loads without significant reconfiguration.\n\n3. **Security**:\n   - Implements best practices for security, including network isolation, encryption, and least-privilege access.\n\n4. **Reproducibility**:\n   - IaC ensures that the infrastructure can be reproduced reliably across different environments and regions.\n\n5. **Version Control**:\n   - All configurations are version-controlled, enabling tracking of changes and facilitating collaboration.\n\n### Design Highlights\n\n- **Automation**:\n  - Utilizes Terraform scripts to automate the provisioning and management of infrastructure, reducing manual errors and increasing efficiency.\n\n- **Integration with CI/CD**:\n  - The IaC setup is integrated with CI/CD pipelines, ensuring that infrastructure changes are tested and deployed alongside application code.\n\n- **GitOps with ArgoCD**:\n  - Ensures that the deployed infrastructure and applications are always in sync with the Git repository, enhancing reliability and traceability.\n\n---\n\n## Conclusion\n\nThis solution outlines a comprehensive approach to containerizing a web application, deploying it to Kubernetes, establishing robust CI/CD pipelines, ensuring secure and scalable deployments, and codifying the entire infrastructure as code. By leveraging industry best practices and modern tools like Docker, Kubernetes, Helm, GitHub Actions, ArgoCD, and Terraform, the system is designed for reliability, security, and scalability, facilitating efficient development and operational workflows.\n\n---\n\n## Repository References\n\n- **Dockerfile**: [fta_users/Dockerfile](https://github.com/greyhats13/fta_users/blob/main/Dockerfile)\n- **Kubernetes Deployments**: [fta_gitops Repository](https://github.com/greyhats13/fta_gitop)\n- **CI/CD Pipeline**: [fta_users GitHub Actions Workflow](https://github.com/greyhats13/fta_users/blob/main/.github/workflows/github-ci.yml)\n- **Infrastructure as Code**: [fta_iac Repository](https://github.com/greyhats13/fta_iac)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgreyhats13%2Ffta_users","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgreyhats13%2Ffta_users","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgreyhats13%2Ffta_users/lists"}