Gitlab is a powerful tool that allows creating any process to automate our application lifecycle, from building and deploying. Also, today we will see how to deploy Elastic Beanstalk. Also, it’s a powerful product from AWS that automates the creation of one computer on the cloud, combining those two tools, which will improve our process ever forwarder.
To use Gitlab and deploy the Elastic Beanstalk, we will need to build one docker image with the Elastic Beanstalk CLI command-line tool, or you can install it every time you trigger the pipeline. In my case, I prefer to create one Docker Image and cache it on my Gitlab Runner, so the next interaction with the pipeline will be much faster.
Building a Docker Image with AWS Tools
Let’s see how you can build the Docker Image if you prefer to do it.
FROM ubuntu:18.04
RUN apt-get update && apt-get install -y \
build-essential zlib1g-dev libssl-dev libncurses-dev \
libffi-dev libsqlite3-dev libreadline-dev libbz2-dev
RUN apt-get install -y git curl wget python-pip zip
RUN git clone https://github.com/aws/aws-elastic-beanstalk-cli-setup.git
RUN ./aws-elastic-beanstalk-cli-setup/scripts/bundled_installer
RUN pip install awscli
RUN echo 'export PATH="/root/.ebcli-virtual-env/executables:$PATH"' >> ~/.bash_profile && source ~/.bash_profile
The main dependencies from our Docker Image are the Elastic Beanstalk CLI and AWS CLI tools.
In my scenario, I am building this image with that command and name:
docker build -t myimage/aws-tools:latest .
Check also our other post, how to deploy Cloud Formation using Gitlab.
Gitlab Elastic Beanstalk Deploy
Now let’s see how the gitlab-ci.yml will look like:
variables:
AWS_REGION: us-east-1
APP_NAME: bitslovers-app
ENV_NAME: bitslovers-env
FILE: $CI_COMMIT_REF_NAME-$CI_PIPELINE_ID
BUCKET: app-versions
BUCKET_PREFIX: dev/
AWS_PLATFORM: Docker
KEY: my-keypair-name
stages:
- deploy
deploy:
stage: deploy
image: myimage/aws-tools:latest
when: manual
script:
- export FILE=$FILE-$(date +%s%N).zip
- echo $FILE
- zip -r $FILE * .ebextensions/
- export AWS_DEFAULT_REGION=us-east-1
- aws s3 cp $FILE s3://$BUCKET/$BUCKET_PREFIX$FILE
- aws elasticbeanstalk create-application-version --application-name $APP_NAME --version-label $FILE --source-bundle S3Bucket=$BUCKET,S3Key=$BUCKET_PREFIX$FILE
- source ~/.bash_profile
- eb init -i ${APP_NAME} -p ${AWS_PLATFORM} --region ${AWS_REGION} -k ${KEY}
- eb deploy ${ENV_NAME} --version $FILE --timeout 60
# - aws elasticbeanstalk update-environment --application-name $APP_NAME --environment-name $ENV_NAME --version-label $FILE
Let’s talk about some variables from this pipeline:
On AWS Elastic Beanstalk, we have two names that help identify our application: The Application Name (APP_NAME) and Environment Name (ENV_NAME), so change it according to your configuration.
KEY variables represent the keypair name that is configured on your environment and region. It doesn’t make sense to me, but it’s required for the eb command.
AWS_PLATFORM, it’s the platform chosen by you when you create your application. In our scenario, we are using Docker. But it could be anyone like .NET, GlassFish, Go, Java, Node.js, PHP, Python, Ruby, or Tomcat.
The BUCKET and BUCKET_PREFIX are the information, which S3 Bucket name and prefix, where the Application Version, will be stored in the Zip file with our configurations. Later, AWS will use this S3 Object to deploy our application on Elastic Beanstalk.
The FILE variable store the filename for the ZIP file. Remember that we use it on the version-label parameter, so it needs to be different for each deployment. If you change the logic to give another name for the ZIP file, make the Application Version different. Otherwise, you can see an error message like this:
An error occurred (InvalidParameterValue) when calling the CreateApplicationVersion operation: Application Version FILE already exists.
And last but not least, change the AWS_REGION to match your environment.
Gitlab Elastic Beanstalk Deploy: Step-by-step
On the script session, from lines 19 to 24, we create the zip file and upload it to an S3 Bucket to generate the Application Version on the Elastic Beanstalk, and later you can use it to deploy your application.
Let’s talk about the two different approaches to trigger the pipeline that it’s the last command on the script, lines 26 and 27.
Line 27 it’s commented on because it behaves differently from line 26, but both do the same goal: deploy the elastic beanstalk. However, line 27 doesn’t wait for the deployment on AWS to finish. So, when you trigger the pipeline, the script is finished immediately, and Gitlab makes the pipeline as completed regardless of if something wrong happens on the AWS side. So, you need to go through the AWS Console and keep monitoring the process there.
However, line 26 waits for the deployment to finish on AWS and stream the GitLab pipeline logs. So, if something wrong happens, you can see error logs without opening the AWS Console. Also, it’s a good approach if other people don’t have access to the AWS Console.
Of course, it’s up to you to decide which one it’s ideal for you.
Conclusion
Deploying the Elastic Beanstalk on Gitlab only requires a few lines and one Docker Image.
Please leave a comment and follow me on Twitter.
