Automating Dockerized Application Delivery via GitLab CI/CD to AWS Elastic Beanstalk

The orchestration of modern web applications requires a seamless bridge between version control and infrastructure provisioning. AWS Elastic Beanstalk serves as a critical abstraction layer that manages the complexities of capacity provisioning, load balancing, auto-scaling, and application health monitoring. When integrated with a robust DevOps platform like GitLab, organizations can transition from manual deployment cycles to a continuous delivery model. This integration allows developers to define their application stacks with high flexibility, particularly when utilizing Docker, which ensures that the environment in which the code is developed is identical to the environment in which it is executed. By leveraging GitLab CI/CD, GitLab Runner, and the GitLab Container Registry, a comprehensive pipeline can be established that automatically triggers builds and deployments upon every code commit, thereby reducing the time-to-market and minimizing human error during the release process.

Infrastructure Foundations and Environment Setup

The establishment of a deployment pipeline begins with the correct configuration of the hosting environment. For a GitLab-driven workflow on AWS, the initial phase involves the deployment of the GitLab environment itself.

The process typically begins by setting up GitLab on an Amazon Elastic Compute Cloud (Amazon EC2) instance. This instance is hosted within a new Amazon Virtual Private Cloud (Amazon VPC), providing a secure, isolated network environment. The VPC ensures that the GitLab server and the subsequent Elastic Beanstalk environments can be managed with specific networking rules, enhancing security and traffic control.

Once the GitLab instance is operational, the following administrative tasks are required:

• Establishing SSH access to the GitLab environment to allow for secure remote management and configuration.
• Configuring GitLab CI/CD deployment tokens. These tokens are vital for secure authentication between the GitLab CI/CD pipeline and the AWS environment, ensuring that only authorized processes can trigger deployments.

The operational flow for the deployment of a sample Node.js application involves a sequence of five primary stages:

1. The initialization of the GitLab environment on Amazon EC2 within a dedicated Amazon VPC, where a repository containing the Node.js application is populated.
2. The configuration of the deployment pipeline, which integrates GitLab CI/CD, the GitLab Runner, and the GitLab Container Registry.
3. The provisioning of a sample Elastic Beanstalk application and its associated environment.
4. The update of application code within the GitLab repository.
5. The automatic initiation of the build and deployment process to the Elastic Beanstalk environment via the CI/CD pipeline.

Technical Prerequisites for Development and Deployment

To successfully implement this architecture, specific software and access rights must be present on the local development machine and within the AWS account.

The following requirements are mandatory for the execution of the workflow:

• An active AWS account with full access to the necessary AWS services, specifically Elastic Beanstalk and EC2.
• Node.js and npm installed locally. For macOS users, this is achieved via the commands brew update and brew install node. For Windows users, the official Node.js installer is used, which includes the npm package manager.
• The TypeScript compiler (tsc), as the sample application is written in TypeScript (a superset of JavaScript). Installation is performed via the command npm install -g typescript.

It is critical to note that specific templates and code provided for these demonstrations are designed to function exclusively within the us-east-1 region.

Docker Integration and Containerization Workflow

The use of Docker within Elastic Beanstalk provides the highest level of flexibility for developers. Instead of relying on the pre-configured platform versions provided by AWS, developers can define their own stacks, including specific OS versions, system libraries, and runtime configurations.

In a typical GitLab CI/CD pipeline for Docker, the process follows a strict sequence:

• The GitLab Runner identifies a code change in the repository.
• A Docker image is built based on the application's Dockerfile.
• This image is pushed to the GitLab Container Registry, which acts as the central repository for all versioned images.
• The Elastic Beanstalk environment is then instructed to pull the specific image from the GitLab Container Registry and deploy it.

This method ensures that the deployment is immutable; the exact image tested in the CI stage is the one deployed to production, eliminating the "it works on my machine" phenomenon.

Continuous Integration and Deployment Pipeline Execution

The GitLab CI/CD pipeline is the engine that drives the automation. When a developer pushes code to the repository, GitLab triggers a pipeline that can be monitored via the GitLab console.

For a Node.js application, the workflow involves modifying the source code and pushing it to the master branch. For example, to update a route file, a developer would perform the following steps in the terminal:

bash cd ~/test/sample-nodejs-app cd src/routes vi MyOffice.ts

After editing the file (e.g., adding an <h3> tag to the body section), the changes are committed and pushed:

bash cd ~/test/sample-nodejs-app/src/routes git add MyOffice.ts git commit -m "Updated MyOffice.ts file" git push -u origin master

Once the git push command is executed, the GitLab console under CI/CD > Pipelines displays the automated run. The pipeline handles the building of the Docker container, pushing it to the registry, and updating the Elastic Beanstalk environment.

To verify the deployment, the user navigates to the Elastic Beanstalk console, selects the environment (e.g., SampleBeanstalkGitLabEnvironment), and selects "Go to environment" to view the live application.

Advanced Laravel Deployment and Configuration

While Docker provides a generic containerization path, deploying specific frameworks like Laravel requires additional considerations regarding the filesystem and server configuration.

One common pitfall in Laravel deployments involves the .gitignore file. Certain configurations may inadvertently include lines that prevent the .elasticbeanstalk folder from being tracked. If the following lines appear in .gitignore, they must be deleted to ensure GitLab can process the necessary configuration files:

• .elasticbeanstalk/*
• !.elasticbeanstalk/*.cfg.yml
• !.elasticbeanstalk/*.global.yml

Post-deployment for Laravel requires ensuring that the remote /vendor folder is populated and the database schema is current. This is achieved by executing the following commands on the remote server:

bash composer install php artisan migrate

To automate these tasks and configure the server environment, Elastic Beanstalk utilizes .ebextensions. These are YAML files located in the .ebextensions folder at the root of the project that instruct the AWS server to run specific commands during the deployment lifecycle. These files are essential for:

• Directing Elastic Beanstalk to serve the application from the /public folder.
• Configuring Apache to redirect all HTTP requests to HTTPS for mandatory SSL security.

Users can import the necessary configuration files from a known repository using the following command:

bash svn export https://github.com/mjsarfatti/laravel-eb-gitlab-ci/trunk/.ebextensions

The final piece of the Laravel automation is the .gitlab-ci.yml file, which defines the stages, scripts, and artifacts that GitLab should handle during the deployment process.

Comparative Analysis of CI/CD Tooling for Elastic Beanstalk

AWS Elastic Beanstalk is designed to be agnostic regarding the CI/CD tool used. While GitLab is a powerful choice, other tools provide different integration paths.

Summary of Resource Management and Cleanup

To avoid unnecessary costs, it is imperative to manage AWS resources diligently. After the testing and verification of the GitLab and Elastic Beanstalk integration, all deployed resources must be removed. This includes:

• Un-provisioning the Elastic Beanstalk application and environment.
• Terminating the GitLab service and its associated Amazon EC2 instance.

Failure to remove these resources can lead to ongoing charges for compute and storage, even if the application is not actively serving traffic.

Analysis of the Integration Architecture

The integration of GitLab with AWS Elastic Beanstalk represents a sophisticated approach to software delivery that balances developer autonomy with operational stability. By using Docker as the deployment unit, the architecture decouples the application from the underlying infrastructure, allowing for seamless upgrades of the runtime environment without altering the application code.

The use of .ebextensions allows for a "Configuration as Code" approach, ensuring that server-level changes (such as Apache redirects or composer installations) are versioned and repeatable. This eliminates the need for manual SSH intervention, which is a critical requirement for achieving true continuous deployment.

The effectiveness of this pipeline is rooted in the synchronization between the GitLab Container Registry and the Elastic Beanstalk environment. The pipeline does not merely move code; it moves a verified, immutable artifact. This significantly reduces the risk of deployment failures caused by missing dependencies or environment mismatches. When compared to traditional deployments, the combination of GitLab CI/CD and Elastic Beanstalk provides a scalable framework that supports both simple Node.js microservices and complex PHP frameworks like Laravel, making it a versatile choice for modern enterprise deployments.

Sources

1. Deploy a Docker application on AWS Elastic Beanstalk with GitLab
2. Deploy Laravel to AWS Beanstalk with GitLab CI
3. Implementing CI/CD integration with your Elastic Beanstalk environment