Automate deployment with Gitlab CI/CD and AWS S3
制作・開発Deploying static sites to AWS S3 can be a tedious repetitive manual process, but with Gitlab CI/CD, you can automate your deployment workflow efficiently.
This guide will walk you through setting up an automated CI/CD pipeline to make your development process more reliable.
What is deployment automation?
Automating deployment is setting up a pipeline that will automatically move your code changes to a server or hosting service, in this case an S3 bucket, whenever you make changes to your code.
Why automate deployment?
Automating deployment offers numerous advantages that enhance the development process. Some of these include:
- Reduced manual effort: it allows you to focus on coding while it takes care of the files update
- Enhanced speed: it speeds up the deployment process for faster, more frequent updates
- Minimized errors: it’s less prone to human error, leading to more reliable deployments
- Continuous delivery: always in a deployable state. Every change made is automatically ready for deployment at any time
How to automate deployment?
To automate deployment, there are few steps to be performed both on the AWS side and the Gitlab side. Let’s go through them:
The AWS side
For the pipeline to access your S3 bucket, you will need to have an IAM user with the necessary permissions.
- Go to the AWS Management Console
- Navigate to Identity and Access Management (IAM)
- Create a new user with the AmazonS3FullAccess managed policy, or create a custom policy tailored to your specific needs
- Follow the prompts to create the user and generate access keys (Access Key ID and Secret Access Key) that will be used later on.
The Gitlab side
On the Gitlab side, start by setting the necessary variables within your existing Gitlab project. To do this, go to Settings → CI/CD
You will need to add the following variables:
- AWS_ACCESS_KEY_ID: this is the Access Key generated in the previous step
- AWS_SECRET_ACCESS_KEY: this the Secret Access Key generated in the previous step
- AWS_DEFAULT_REGION: this is the default region of your AWS account, usually found on the top right of the AWS Management Console
- S3_BUCKET: this variable will hold the name of your S3 bucket.
If your S3 bucket is in a different region from the AWS default region, as in the example below, you need to create an additional variable S3_BUCKET_REGION to store the region information.
The CI/CD variables should look something like this:
Creating the .gitlab-ci.yml file
Now you’re ready to write your .gitlab-ci.yml file. This file defines the CI/CD pipeline stages, and the steps to deploy your files.
Let’s break down the above code.
- image: specifies the Docker image to use, in our case, it’s the latest AWS CLI.
- entrypoint: to ensure that commands are executed in a shell
- stages: defines the pipeline stages. You can name the stages however you see fit. In this example, we use a single stage named deploy.
- Deploy:
- stage: specifies the stage this job belongs to
- only: specifies the branch this job should run on, here “main” branch
- script: the commands to be executed. It starts by setting AWS CLI with the provided information, then syncing the repository content to the specified S3 bucket.
Testing
To confirm your changes, push your code to your Gitlab branch and verify that the pipeline passes successfully. This ensures that the automated deployment process was set up correctly.