Skip to main content
Mapagam

Deploying to Cloud Platforms

1. Deploying to AWS

Example: Basic AWS Deployment Configuration

deploy:
  stage: deploy
  script:
    - apt-get update -y
    - apt-get install -y awscli
    - aws s3 sync ./dist s3://my-bucket/dist --delete
  only:
    - main
Option Values Notes
aws_access_key_id AKIAIOSFODNN7EXAMPLE Required for AWS authentication
aws_secret_access_key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Required for AWS authentication
region us-east-1 AWS region to deploy to
Note: Ensure that the AWS credentials are stored as GitLab CI/CD variables for security.

Example: Deploying to AWS Lambda

deploy_lambda:
  stage: deploy
  script:
    - apt-get update -y
    - apt-get install -y zip
    - zip -r function.zip index.js
    - aws lambda update-function-code --function-name my-function --zip-file fileb://function.zip
  only:
    - main

Deployment Options Comparison

  • AWS S3: Best for static websites or file storage
  • AWS Lambda: Serverless compute for event-driven functions
  • AWS ECS/EKS: Container orchestration for scalable applications

2. Using AWS ECS Deployments

Option Values Description
deploy.target aws_ecs Target deployment platform for ECS
deploy.region us-east-1 AWS region where ECS cluster is located
deploy.cluster my-cluster Name of the ECS cluster to deploy to
deploy.service my-service Name of the ECS service to update
deploy.task_definition my-task-definition.json Path to ECS task definition file

Example: Deploying to AWS ECS

deploy_to_ecs:
  stage: deploy
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - echo "Deploying to AWS ECS..."
    - aws ecs update-service --cluster my-cluster --service my-service --task-definition my-task-definition.json
  only:
    - main
Note: Ensure that the AWS CLI is configured with appropriate permissions to update ECS services.
Warning: The task_definition must be updated in AWS ECS before deploying to ensure compatibility.
Deployment Parameter Required Description
aws_access_key_id Yes AWS access key ID for authentication
aws_secret_access_key Yes AWS secret access key for authentication
region Yes AWS region where ECS cluster is located
cluster Yes Name of the ECS cluster to deploy to
service Yes Name of the ECS service to update

3. Deploying to Google Cloud

Option Values Notes
gcloud gcloud Google Cloud SDK command-line tool
project_id my-gcp-project Google Cloud project ID
region us-central1 Deployment region

Example: Deploying to Google App Engine

gcloud app deploy --project=my-gcp-project --version=v1

Example: Deploying to Google Kubernetes Engine

deploy:
  stage: deploy
  script:
    - gcloud container clusters get-credentials my-cluster --zone us-central1-a
    - kubectl set image deployment/my-app my-app=nginx:latest
Note: Ensure the GitLab CI runner has appropriate Google Cloud credentials configured via service account key or Workload Identity.
Warning: Make sure to set up proper IAM roles for the service account used in GitLab CI to avoid deployment failures.

4. Using Azure Deployments

Property Value Description
deploy.azure.subscription_id string Azure subscription ID for deployment
deploy.azure.resource_group string Name of the resource group to deploy to
deploy.azure.app_service_name string Name of the Azure App Service to deploy to
deploy.azure.location string Region where the deployment will occur

Example: Deploying to Azure App Service

deploy_to_azure:
  stage: deploy
  image: mcr.microsoft.com/azure-cli:latest
  script:
    - az login --service-principal -u $AZURE_CLIENT_ID -p $AZURE_CLIENT_SECRET --tenant $AZURE_TENANT_ID
    - az webapp deployment source config-zip --resource-group $AZURE_RESOURCE_GROUP --name $AZURE_APP_SERVICE_NAME --src-path ./app.zip
  environment:
    name: production
    url: https://$AZURE_APP_SERVICE_NAME.azurewebsites.net
  only:
    - main
Note: Ensure that the AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, and AZURE_TENANT_ID are set as GitLab CI/CD variables in your project settings.
Warning: The az webapp deployment source config-zip command requires the application to be packaged as a ZIP file.

Deployment Steps

  • Login to Azure using service principal credentials
  • Deploy application ZIP file to the specified App Service
  • Set environment URL for easy access

5. Deploying to Heroku

Option Values Description
heroku.app my-app Name of the Heroku application
heroku.region us Region where the app is deployed (e.g., us, eu)
heroku.buildpack https://github.com/heroku/heroku-buildpack-nodejs Buildpack used to build the application

Example: Deploying to Heroku

deploy:
  stage: deploy
  image: heroku/cli:latest
  script:
    - heroku container:push web --app $HEROKU_APP_NAME
    - heroku container:release web --app $HEROKU_APP_NAME
  only:
    - main
Note: Ensure that the HEROKU_APP_NAME and HEROKU_API_KEY are set as GitLab CI/CD variables.
Warning: The Heroku CLI must be installed in the Docker image used for deployment.

6. Using DigitalOcean Deployments

Option Values Notes
deploy digitalocean Deploy target for DigitalOcean
region nyc1 Region to deploy to (e.g., nyc1, sfo2)
app_name my-app Name of the DigitalOcean App Platform app

Example: Deploy to DigitalOcean App Platform

deploy:
  image: registry.gitlab.com/gitlab-org/gitlab-ci-templates/deploy-to-digitalocean:latest
  variables:
    DO_TOKEN: $DIGITALOCEAN_ACCESS_TOKEN
    REGION: nyc1
    APP_NAME: my-app
Note: Requires a DigitalOcean API token with appropriate permissions.
Warning: Ensure that the APP_NAME matches an existing app on DigitalOcean.

Deployment Process

  • GitLab CI triggers the deployment job
  • Uses the official GitLab template for DigitalOcean
  • Deploys to the specified region and app name

7. Deploying Serverless Functions

Option Values Description
deploy.target aws_lambda, azure_functions, google_cloud_functions Target cloud platform for serverless deployment
deploy.region us-east-1, eu-west-1 Region to deploy the function
deploy.function_name my-function Name of the function to deploy

Example: Deploying to AWS Lambda

deploy_to_lambda:
  stage: deploy
  image: python:3.9
  script:
    - pip install awscli
    - aws lambda update-function-code --function-name my-function --zip-file fileb://function.zip
  only:
    - main
Note: Ensure that the AWS credentials are configured in GitLab CI/CD variables.
Warning: The function code must be packaged in a ZIP file for AWS Lambda deployment.

8. Configuring Terraform Deployments

Example: Basic Terraform Deployment Configuration

deploy:
  stage: deploy
  script:
    - terraform init
    - terraform apply -auto-approve
  environment:
    name: production
    url: https://app.example.com
Property Description Values
terraform init Initializes a Terraform configuration terraform init
terraform apply Applies the Terraform configuration terraform apply -auto-approve
environment.name Name of the deployment environment production, staging
environment.url URL of the deployed application https://app.example.com
Note: Ensure that the necessary credentials and variables are set in GitLab CI/CD variables or secrets.
Warning: Using -auto-approve in production environments is risky and should be used with caution.

9. Using Infrastructure as Code

Resource Description Example Notes
module Defines a reusable component in Terraform 
module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  cidr = "10.0.0.0/16"
}
 Can be local or remote
provider Defines the cloud provider for resources 
provider "aws" {
  region = "us-west-2"
}
 Must be declared before resources
resource Represents a managed resource in the cloud 
resource "aws_instance" "web" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
}
 Unique identifier via id
variable Input values for modules or configurations 
variable "instance_count" {
  type    = number
  default = 1
}
 Can have validation rules
output Exports values from Terraform configuration 
output "instance_id" {
  value = aws_instance.web.id
}
 Useful for integration with other tools

Example: Deploying a VPC with GitLab CI

deploy_vpc:
  stage: deploy
  script:
    - terraform init
    - terraform apply -auto-approve
  environment:
    name: production
  only:
    - main
Note: Ensure that Terraform state is stored securely, such as in an S3 bucket with versioning enabled.
Warning: Never commit sensitive data like AWS credentials to version control.

Key Concepts in IaC with GitLab CI

  • State Management: Terraform uses a state file to track resource metadata.
  • Module Reuse: Modules allow for abstraction and reuse of infrastructure components.
  • Environment Isolation: Use different workspaces or variables for dev/staging/prod.

10. Managing Cloud Credentials

Credential Type Configuration Method Description Security Notes
GitLab CI/CD Variables Settings > CI/CD > Variables Store credentials as masked or protected variables in GitLab. Variables are encrypted at rest and only available to jobs with proper access.
GitLab CI/CD Secret Variables Settings > CI/CD > Variables Securely store sensitive values like API keys or tokens. Masked variables are not shown in logs. Protected variables are only available to protected branches or tags.
AWS Credentials CI/CD Variables Use AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. Store keys securely and rotate them regularly. Avoid hardcoding in scripts.
Azure Credentials CI/CD Variables Use AZURE_SUBSCRIPTION_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET. Use managed identities where possible. Rotate secrets periodically.
Google Cloud Credentials CI/CD Variables Use GOOGLE_CREDENTIALS (JSON key) or GCP_SERVICE_ACCOUNT_KEY. Ensure service account has minimal required permissions. Rotate keys regularly.

Example: Using AWS Credentials in a Job

deploy:
  stage: deploy
  script:
    - echo "Deploying to AWS"
    - aws s3 sync ./dist s3://my-bucket
  variables:
    AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
    AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
Note: Ensure that the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables are set as masked or protected in GitLab CI/CD settings.
Warning: Never expose credentials in logs or commit them to version control. Use GitLab's built-in variable management for sensitive data.

Was this article helpful?

Related Cheat Sheets