DEV Community: Ednah

A Beginner's Guide to Docker Image Commands: Managing Docker Images

Ednah — Wed, 13 Mar 2024 19:22:57 +0000

In the world of containerization, Docker has emerged as a dominant force, simplifying the way developers build, ship, and run applications. At the core of Docker's functionality are Docker images, lightweight, standalone, executable packages that contain everything needed to run a piece of software, including the code, runtime, libraries, and dependencies.

Managing Docker images is a crucial aspect of working with Docker, and understanding the various Docker image commands is key to efficiently handling your Docker images. In this blog post, we'll explore some of the most common Docker image commands, demystifying their usage and highlighting best practices along the way.

Whether you're just getting started with Docker or looking to enhance your Docker skills, this guide will equip you with the knowledge you need to manage Docker images like a seasoned pro. Let's dive in!

Docker pull

This command downloads a docker image from a public or private registry (example being Docker Hub) to your local image.

Docker images are stored in repositories, which can be public (like Docker Hub) or private (self-hosted or on a different registry). Thus, when you use docker pull, Docker contacts the specified registry and downloads the image to your local machine. If the image already exists locally, Docker will check if there is a newer version available on the registry and download it if necessary.

Syntax

docker pull <image_name>:<tag>

Example

docker pull ubuntu:latest

This downloads the latest version of the official Ubuntu image.

docker images

This command will list all Docker images that are currently available on your local system.

Docker images are stored locally on your machine after being downloaded from a registry or built using a Dockerfile. The docker images command provides a list of all these images, along with their repository name, tag, image ID, and size. It allows you to see what images you have available to use for creating and running containers.

You can use the output of docker images to manage your images, such as removing images that are no longer needed or checking the versions of images that you have downloaded. Images listed as in the repository column are usually intermediate images created during the build process and can be removed using docker rmi.

Syntax

docker images

Example

In this example, the output shows three images: nginx with the latest tag, mysql with the 5.7 tag, and an unnamed image (with repository and tag set to ) that can be removed if not needed.

docker run

docker run creates a running container instance from a certain docker image

When you run docker run , Docker looks for the specified image locally. If the image is not found locally, Docker will attempt to download it from a registry before creating the container.

You can also specify options and arguments with the docker run command to customize the container's behavior, such as setting environment variables, exposing ports, or mounting volumes.

Syntax

docker run [options] <image_name>:<tag> [command] [arguments]

Options (e.g., -dfor detached mode, -p for port mapping) can be used to customize container behavior.
Replace <image_name> and <tag>as explained earlier.
command (optional): The command to run within the container.
arguments (optional): Arguments to pass to the command.

Example

Let’s look at an example to understand this syntax better

docker run -d --name my-container -p 8080:80 nginx:latest nginx -g 'daemon off;'

In the above example the following have been used:

Options: -d, --name, -p are options that modify the behavior of the docker run command.
-d runs the container in detached mode, meaning it runs in the background.
--name my-container sets the name of the container to my-container.
-p 8080:80maps port 8080 on the host to port 80 in the container, allowing you to access the nginx web server running in the container from your host machine at http://localhost:8080.
Image name and tag: nginx:latest specifies the Docker image to use (nginx in this case) and its tag (latest).
Command: nginx -g 'daemon off;' is the command that overrides the default command specified in the Dockerfile and is executed when the container starts.

Here’s another simpler example:

docker run -it ubuntu:latest bash

This starts a new container based on the ubuntu:latest image in interactive mode (-it) and start an interactive Bash shell inside that container. This allows you to execute commands and interact with the Ubuntu environment within the container.

docker inspect

Displays detailed information about a specific Docker image.

In general, The docker inspect command provides detailed information about a Docker object, such as an image or container. It returns a JSON object containing various metadata and configuration details.

When used with an image, docker inspect provides information like the image ID, size, tags, creation date, and details about the image's layers.

When used with a container, docker inspect provides information about the container's configuration, network settings, volumes, and more.

You can use docker inspect to troubleshoot issues, understand how images or containers are configured, and retrieve specific details for scripting or automation purposes.

Syntax

docker inspect <image_or_container_id>

Example on an Image

docker inspect ubuntu:latest

Output

[
    {
        "Id": "sha256:3339fe25b7e8c0da71a528d937d7acae0861dfb6421ee8bce4b5a605cb14059a",
        "RepoTags": [
            "ubuntu:latest"
        ],
        "RepoDigests": [],
        "Parent": "",
        "Comment": "",
        "Created": "2022-01-01T00:00:00.000000000Z",
        "Container": "",
        "ContainerConfig": {
            "Hostname": "abcd1234",
            "Domainname": "",
            "User": "",
            ...
        },
        ...
    }
]

Here’s an explanation of a few key elements from the above output

"Id": "sha256:3339fe25b7e8c0da71a528d937d7acae0861dfb6421ee8bce4b5a605cb14059a": Unique identifier (SHA256 hash) for the container.
"RepoTags": ["ubuntu:latest"]: Tags associated with the image, in this case, the latest tag for the ubuntu repository.
"Created": "2022-01-01T00:00:00.000000000Z": Date and time when the container was created.
"ContainerConfig": { ... }: Configuration details for the container, such as hostname, domain name, user, etc. This section provides the configuration used when a container is created from this image.

Example on a container

docker inspect my-container

Output

[
    {
        "Id": "abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234",
        "Created": "2022-01-01T00:00:00.000000000Z",
        "Path": "bash",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            ...
        },
        "Image": "sha256:3339fe25b7e8c0da71a528d937d7acae0861dfb6421ee8bce4b5a605cb14059a",
        "...
    }
]

Here’s an explanation of a few key elements from the above output

"Id":"abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234": Unique identifier (SHA256 hash) for the container.
"Created": "2022-01-01T00:00:00.000000000Z": Date and time when the container was created.
"Path": "bash": The path to the command that was run when the container was started. In this case, it is bash. This means that when the container was started, it executed the bash command as its main process. In Docker, the command specified after the image name in the docker run command (or the default command specified in the Dockerfile if no command is specified) is the initial command that the container runs. In this case, the bash command is commonly used to start an interactive shell within the container.
"State": { "Status": "running", "Running": true, ... }: Information about the current state of the container, such as whether it is running, paused, or stopped.
"Image": "sha256:3339fe25b7e8c0da71a528d937d7acae0861dfb6421ee8bce4b5a605cb14059a": The image used to create the container, identified by its image ID.

docker build

Build a Docker image from a Dockerfile and context.

The Dockerfile contains instructions on how to build the image, such as which base image to use, what commands to run, and what files to include.

docker build command reads the Dockerfile and executes the instructions to create a new Docker image.

The context is the set of files and directories located at the specified PATH or URL. These files are sent to the Docker daemon for building the image. What this means is, when you use docker build to create a Docker image, you provide a "context" to the Docker daemon. This "context" is simply the set of files and directories that Docker will use to build the image. For example, if you run docker build ., the current directory (denoted by .) and all its files and subdirectories will be sent to Docker as the context. Docker will then use these files to follow the instructions in your Dockerfile and create the image.

Each instruction in the Dockerfile adds a new layer to the image, allowing for efficient reuse of layers between images.

Syntax

docker build [OPTIONS] PATH | URL

Some options that can be pass to this command include:

-t, --tag: Name and optionally a tag in the 'name:tag' format to apply to the resulting image.
--build-arg: Set build-time variables that are accessed like environment variables in the Dockerfile.
-f, --file: Name of the Dockerfile (Default is 'PATH/Dockerfile').
--force-rm: Always remove intermediate containers, even after unsuccessful builds.
--no-cache: Do not use cache when building the image.
--pull: Always attempt to pull a newer version of the base image before building.

Example:

docker build -t my-image:latest .

In this example, docker build would build a Docker image named my-image with the tag latest using the Dockerfile located in the current directory (.).

docker save

This command saves a Docker image as a tar archive to the local filesystem.

It is used to export a Docker image as a tarball file (A tarball file is a file archive format used to bundle files and directories together, commonly used in Unix and Linux systems. In Windows, the equivalent of a tarball file would be a ZIP file.), which allows you to save the image locally or transfer it to another machine.

The saved tarball contains all the layers of the Docker image, along with its metadata.

Once saved, you can use docker load (next command below) to import the image back into Docker on the same or another machine. This command is useful for creating backups of Docker images or sharing them with others who do not have direct access to a Docker registry.

Syntax

docker save <image_name>:<tag> -o <output_file.tar>

Example

docker save ubuntu:latest -o ubuntu_latest.tar

In this example, the docker save command saves the ubuntu:latest image as a tarball file named ubuntu_latest.tar.

docker load

This command loads a docker image from a tar archive

It is used to import a Docker image that was previously saved as a tarball file using the docker save command. It reads the tarball file and imports the image into the Docker image repository on your local system.

After loading the image, you can use it to create and run containers as you would with any other Docker image.

Syntax

docker load <image_tar_file>  # Load from a tar archive
docker load  # Load from standard input (STDIN)

Example

docker load -i ubuntu_latest.tar

In this example, the docker load command imports the ubuntu_latest.tar tarball file, which contains a Docker image, into the local Docker image repository.

This command essentially enables you to import Docker images from external sources like tar archives, allowing you to use pre-built or custom images without directly pulling them from a registry.

docker tag

This command creates a tag for an existing docker image

Tags are used to identify different versions or variants of an image. By default, Docker images are tagged with latest if no tag is specified. However, it's good practice to use explicit tags to version your images.

Tags are specified in the format :, where is the name of the image repository and is the tag you want to assign to the image. After tagging an image, you can use the new tag to reference the image when running containers or pushing it to a registry.

Syntax

docker tag <image_name>:<existing_tag> <image_name>:<new_tag>
docker tag <source_image_name>:<source_tag> <target_image_name>:<target_tag>

Examples

docker tag ubuntu:latest ubuntu:mytag

In this example, the docker tag command creates a new tag mytag for the ubuntu:latest image, resulting in the image being tagged as ubuntu:mytag.

Here's another example:

docker pull ubuntu:18.04  # Download the Ubuntu 18.04 image
docker tag ubuntu:18.04 my-ubuntu:v1  # Create a custom tag 'v1' for the image

This creates a new tag named v1 for the existing ubuntu:18.04 image.

docker rmi

Removes a Docker image.

This command is used to delete images from your local machine that are no longer needed to free up disk space. It can remove one or more Docker images from your local Docker image cache.

You can specify the image to remove by its name or ID. If the image is in use by a container, you will need to stop and remove the container before you can remove the image. You can use the command docker stop to halt the running container

Syntax

docker rmi <image_name_or_id>

Example

docker rmi ubuntu:mytag
//docker rmi removes the ubuntu:mytag image

docker image prune

Removes unused Docker images from the local system.

This command is used to remove unused images that are not referenced by any containers. It cleans up your local Docker image cache by removing images that are not currently in use, which is useful for freeing up disk space. You can use the -a or --all flag to also remove unused images that have tags other than , which are usually intermediate images created during the build process.

Syntax

docker image prune [OPTIONS]

Options:

-a, --all: Remove all unused images, not just dangling ones.
--filter filter: Provide filter values (e.g., until, label, before) to specify the images to prune.

docker push

This command is used to push a Docker image to a remote registry, such as Docker Hub or a private registry. It allows you to share your Docker images with others or deploy them to production environments.

Before you can push an image, you need to tag it with the name of the registry where you want to push it. This is typically done using the -t flag when building the image or using the docker tag command.

Once the image is tagged, you can use docker push to upload it to the specified registry.

You'll need to authenticate with the registry using docker loginbefore pushing the image.

When you push an image, Docker uploads all the image layers to the registry. This allows others to pull the image and use it on their own systems.

Syntax

docker push <image_name>:<tag>

Example

docker push my-username/my-image:latest

In this example, docker push would push the my-image image with the latest tag to the Docker Hub registry under the my-username account.

Throughout this blog post, we've covered some of the most common Docker image commands, including docker build, docker tag, docker push, and more. We've explored how each command works and how it can be used to enhance your Docker experience.

Start experimenting with Docker image commands today and see how they can transform the way you build, ship, and run your applications.

Happy containerizing!

Introduction to Containerization and Docker

Ednah — Mon, 11 Mar 2024 18:56:16 +0000

In today's fast-paced world of software development, efficiency and agility are key. Developers are constantly seeking ways to streamline their workflows, reduce dependencies, and improve the portability of their applications. This is where Docker comes in. Docker is a powerful tool that allows developers to package their applications and dependencies into lightweight, portable containers that can run consistently across different environments. In this blog, we will explore the fundamentals of containerization, Docker and how it has revolutionized the way we build, ship, and run applications.

What is a Container?

A container is a way to package an application with all the necessary dependencies and configurations it needs. This package is highly portable and can be easily shared and moved around between people, devices and teams. This portability and the compactness of having everything packaged in one isolated environment gives containers the advantages it confers in making development and deployment processes more efficient.

Where do containers live?

As we mentioned, containers are portable. Thus, a question arises. Where are they stored? There must be a place where they are stored, enabling them to be shared and moved around.

Containers are stored in a container repository. This is a special storage area for containers. Many companies have their own private repositories where they host or store all their containers. There are also public repositories such as Dockerhub. In these public repositories, you can browse and find any application container that you want.

Image Above: Dockerhub, a cloud-based registry service that allows you to store and share Docker container images. Docker Hub hosts millions of container images, including official images from Docker and user-contributed images. Users can search for images, pull them to their local environment, and push their own images to share with others.

How do containers improve the development process?

In the era before containers revolutionized development, teams building applications faced a cumbersome process. When a team of developers and engineers are working on an application, they would have to individually install the services needed directly on their operating systems. Suppose the team is building a web application that needs PostgresSQL and Redis. They would each have to install and configure the technologies on their local development environments.

This approach can be tedious and error prone if every developer were to do it individually. Given that each person in the team may have different underlying configurations locally or even operating systems powering their devices, the transferability of the configurations is diminished, probably leading to errors when this application is shared between developers.

With containers, those services/technologies don’t have to be installed directly on a developer's operating system. The container provides a self-contained environment that encapsulates the application and its dependencies, including libraries, binaries, and configuration files. This means that developers can work in a consistent environment regardless of their underlying operating system. Each developer only needs to fetch this established container and run it on their local machines.

How do containers improve the deployment process?

In the traditional deployment process, the development team produces artifacts, such as a JAR file for the application, along with instructions on how to install and configure these artifacts on the server. Additionally, other services, like databases, are included with their own set of installation and configuration instructions. These artifacts and instructions are then handed over to the operations team, who is responsible for setting up the environment for deployment.

However, this approach has several drawbacks. Firstly, configuring and installing everything directly on the operating system can lead to conflicts with dependency versions and issues when multiple services are running on the same host. Secondly, relying on textual guides for instructions can result in misunderstandings between the development and operations teams. Developers may forget to mention important configuration details, or the operations team may misinterpret the instructions, leading to deployment failures.

With containers, this process is simplified because developers and operations teams work together to package the entire application, including its configuration and dependencies, into a single container. This encapsulation eliminates the need to configure anything directly on the server. Instead, deploying the application is as simple as running a Docker command to pull the container image from a repository and then running it. While this is a simplified explanation, it addresses the challenges we discussed earlier by making environmental configuration on the server much easier. The only initial setup required is to install and set up the Docker runtime on the server, which is a one-time effort.

Containers vs Virtual Machines

Containers and virtual machines (VMs) are both used to isolate applications and their dependencies, but they differ in several key ways.

The following are the key differences:

Architecture: VMs virtualize the hardware, creating a full-fledged virtual machine with its own operating system (OS), kernel, and libraries. Containers, on the other hand, virtualize the OS, sharing the host OS kernel but providing isolated user spaces for applications.
Resource Usage: VMs are typically heavier in terms of resource usage because they require a full OS to be installed and run for each VM. Containers are lightweight, as they share the host OS kernel and only include the necessary libraries and dependencies for the application.
Isolation: VMs provide stronger isolation between applications since each VM has its own OS and kernel. Containers share the host OS kernel but provide process-level isolation using namespaces and control groups (cgroups).
Startup Time: Containers have faster startup times compared to VMs, as they do not need to boot an entire OS. VMs can take longer to start as they need to boot a full OS.
Security: While both containers and VMs provide isolation, VMs are often considered more secure due to the stronger isolation provided by virtualizing the hardware. Containers share the host OS kernel, which can potentially introduce security vulnerabilities if not properly configured.

Docker

Now that we have an idea of what containers are, let’s delve into what Docker is.

Docker is an open-source platform that facilitates the development, deployment, and management of applications using containers. It uses the above discussed concepts of containerization to package an application and its dependencies into a single unit, which can then be shared and deployed across different environments without any changes, ensuring consistency.

Here are some key concepts to know with regards to Docker:

Docker Engine:

Docker Engine is an open source containerization technology for building and containerizing your applications. Simply put, it is the workhorse behind the scenes, managing the entire container lifecycle.

It consists of three main components:

Docker Daemon (dockerd): This is a background service that runs continuously on your system. It's responsible for:

Creating and managing containers: The daemon listens for commands from the CLI and interprets instructions to build, run, stop, and manage container instances.
Image management: It handles tasks like pulling images from registries, building images from Dockerfiles, and managing storage for container images and layers.
Network configuration: The daemon sets up networking for containers, allowing them to communicate with each other and the outside world, following configurations you define.
Resource allocation: The daemon manages resource allocation for containers like CPU, memory, and storage, ensuring smooth operation within defined limits.

REST API: This built-in API allows programmatic interaction with Docker Engine. Developers can leverage tools and scripts to automate tasks like container deployment and management through the API.

Docker CLI (docker): This is the user interface most people interact with. It's a command-line tool that communicates with the Docker daemon to execute various commands related to container operations.

Docker Images

Image is the artefact or the application package (application code, runtime, libraries, and dependencies etc) required to configure a fully operational container environment. This is the artefact that can be moved around from device to device or between developers in a team. It is a read-only template containing a set of instructions for creating a container that can run on the Docker platform.

You can create a Docker image by using one of two methods:

Dockerfile: This is the most common method used to create Docker images. A Dockerfile is a text file that contains a series of instructions for building a Docker image. You specify the base image, add any dependencies, copy the application code, and configure the container. Once you have written the Dockerfile, you can build the image using the docker build command. Here’s an example an dockerfile for a Node.js application:

# Use the official Node.js 14 image as the base image
FROM node:14

# Set the working directory in the container
WORKDIR /app

# Copy package.json and package-lock.json to the working directory
COPY package*.json ./

# Install npm dependencies
RUN npm install

# Copy the rest of the application code to the working directory
COPY . .

# Expose port 3000
EXPOSE 3000

# Command to run the application
CMD ["node", "app.js"]

From Existing Container: In this method, you start a container from an existing Docker image, make changes to the container interactively (e.g., installing software, updating configurations), and then save the modified container as a new Docker image using the docker commit command.

While the latter method is possible, it is generally not recommended for production use because it can lead to inconsistencies and difficulties in managing images. Using a Dockerfile to define the image's configuration and dependencies is a more standard and reproducible approach.

Docker Containers

Think of a container as a running image with its own isolated environment. It represents a lightweight, isolated, and portable environment in which an application can run. They are created from images using the docker run command and can be started, stopped, deleted, and managed using Docker commands. Any changes made to a container (e.g., modifying files, installing software) are lost when the container is deleted unless those changes are committed to a new image.

Conclusion

In conclusion, Docker has revolutionized the way we develop, package, and deploy applications. Its lightweight containers provide a flexible and efficient solution for managing dependencies and isolating applications, leading to faster development cycles, improved scalability, and enhanced portability. By simplifying the deployment process and enabling greater consistency across different environments, Docker has become an essential tool for modern software development. As technology continues to evolve, Docker is sure to remain at the forefront, empowering developers and organizations to innovate and deliver high-quality software solutions.

Stay tuned for more articles on Docker.

Happy Dockering!

Deploying a Dockerized React Application to AWS Elastic Beanstalk

Ednah — Sun, 10 Mar 2024 02:29:00 +0000

In this blog post, we will guide you through the process of running a simple React application inside a Docker container. You can find the React app on our GitHub repository here. We will start by preparing the React application for Docker and then move on to setting up Elastic Beanstalk to deploy the application. Finally, we will configure GitHub Actions for automated deployment.

Here’s the blog outline:

Preparing the React Application: Using a Dockerfile to define the environment and dependencies and running the React application inside a Docker container.
Setting up Elastic Beanstalk: Setting up necessary IAM roles, attaching policies and choosing the appropriate configurations for the Dockerized React application.
Configuring GitHub Actions: Setting up GitHub Actions for automated deployment, and configuring environment variables in the GitHub repository secrets.
Testing the Application

Follow along to learn how to deploy your React applications with ease.

Preparing the React application

We will be running a simple React application inside a docker container. You can find the react app on my github repo here.

Create a new folder at a location of your choosing for the react application. To create a docker container for our application, we will run the following command in the folder:

docker run -it -v ${PWD}:/app -p 3000:3000 node:18 sh

This command starts a Docker container based on the node:18 image (node version the application was built on), mounts the current directory to /app inside the container, maps port 3000, and opens an interactive shell session inside the container.

Let's break down the command further:

docker run: This is the command to run a Docker container.
-it: These are two flags combined. -i stands for interactive, which allows you to interact with the container's shell. -t allocates a pseudo-TTY, which helps in keeping the session open and receiving input.
-v ${PWD}:/app: This is a volume mount flag. It mounts the current directory (${PWD}) on the host machine to the /app directory inside the container. This allows the container to access and modify files in the current directory.
-p 3000:3000: This flag maps port 3000 on the host machine to port 3000 inside the container. This is typically used for accessing services running inside the container from outside.
node:18: This specifies the Docker image to use for creating the container. In this case, it's the node image with the tag 18, which presumably refers to a specific version of Node.js.
sh: This is the command to run inside the container. It starts a shell session (sh is a common Unix/Linux shell) so that you can interact with the container's file system and execute commands.

If docker doesn’t find the image locally it will pull it from the remote repository.

Since we started a shell session, after running the command, you will be inside the active shell session. Now cd into the app directory, which is where our application will be.

cd app

We have mapped this directory in our container to our current directory. Thus, any file that you create inside this directory will also reflect on your current directory.

We can now clone our react project into this directory.

git clone https://github.com/Ed-Neema/simpleTodoApp.git

Note that when you interact with a remote Git repository using HTTPS URLs, Git will typically prompt you for your username and password to authenticate (if your Github isn’t globally configured). However, due to changes in GitHub's authentication mechanisms, using a personal access token (PAT) is now required instead of your password for increased security. You may read more about this here.

You can find more detailed information about how to create your personal token here. In summary, here are the steps:

Go to your GitHub account settings.
Navigate to"Developer settings" > "Personal access tokens." > Tokens (classic)
Click on "Generate new token."
Give your token a descriptive name, select the scopes or permissions you'd like to grant this token, and click "Generate token."
Important: Copy your new personal access token. Once you leave or refresh the page, you won’t be able to see it again.

Now that the application has been cloned, let’s create a Dockerfile and a docker compose file.

A Dockerfile is a text file that contains instructions for building a Docker image. It defines the environment inside a Docker container, including the base image to use, any additional dependencies to install, environment variables to set, and commands to run when the container starts. In our case, this is the Dockerfile we need:

This Dockerfile uses a multi-stage build to first build a Node.js application and then sets up an Nginx server to serve the built static files.

Here's a breakdown of each part:

FROM node:18 as builder: This sets the base image to node:18 and assigns it an alias builder. This stage will be used for building the application.
WORKDIR /app/simpleTodoApp: This sets the working directory inside the container to/app/simpleTodoApp. All subsequent commands will be executed relative to this directory.
COPY package.json .: This copies the package.json file from the host machine to the /app/simpleTodoApp directory in the container. This is done before running npm install to take advantage of Docker's layer caching mechanism.
RUN npm install: This installs the dependencies listed in the package.json file.
COPY . .: This copies the rest of the application files from the host machine to the /app/simpleTodoApp directory in the container.
RUN npm run build: This runs the build script specified in the package.json file. This script is typically used to build the production version of the application.
FROM nginx: This starts a new build stage using the nginx base image. This stage will be used for the final image that will run the application.
EXPOSE 80: This exposes port 80 on the container. This is the default port used by Nginx for serving web content.
COPY --from=builder /app/simpleTodoApp/dist /usr/share/nginx/html: This copies the build output from the builder stage (the /app/simpleTodoApp/dist directory) to the Nginx web root directory (/usr/share/nginx/html). This effectively sets up Nginx to serve the static files generated by the Node.js build process. (Note: Since we are using Vite, the builder outputs the built files to the “dist” directory. A pure react app would have its build files in a “build” directory, while a nextjs application would have them in a “.next” directory).

Next, we will create a docker-compose.yml file.

This Docker Compose file defines a service named web that builds a Docker image using the Dockerfile in the current directory and exposes port 80 on the host machine to the container.

Here's a breakdown of each part:

version: '3': This specifies the version of the Docker Compose file format. In this case, it's version 3, which is a widely used version that supports most features.
services: This is the key under which you define the services that make up your application. Each service is a containerized application.
web: This is the name of the service. You can use any name you like to identify your services.
build: This specifies how to build the Docker image for the web service.
context: .: This specifies the build context, which is the path to the directory containing the Dockerfile and any other files needed for the build. In this case, it's set to . (the current directory).
dockerfile: Dockerfile: This specifies the name of the Dockerfile to use for building the image. In this case, it's Dockerfile in the build context.
ports: This specifies the ports to expose on the host machine and the container.
'80:80': This maps port 80 on the host machine to port 80 on the container. This means that you can access the service running in the container on port 80 of the host machine.

Let’s now test whether what we have done works before we deploy to beanstalk.

Run the following command in a new terminal (outside the shell of your container) in your app’s directory:

docker-compose up --build

The docker-compose up --build command is used to build the images for the services defined in your docker-compose.yml file and start the containers. In summary, the command will build the Docker image for the web service using the Dockerfile in the current directory. It will then start the container for the web service and expose port 80 on the host machine, mapping it to port 80 on the container.

This will take a while to build the application’s assets. After it’s done, you should be able to access your application at http://localhost/

Setting up Elastic Beanstalk

We will first start with creating an instance profile.

Creating an EC2 instance profile and attaching the specified policies is necessary when setting up an Elastic Beanstalk environment that uses EC2 instances to run your application. So, navigate to IAM and create an IAM role. The policies that can be attached are the following:

AWSElasticBeanstalkWebTier: This policy provides permissions necessary for the EC2 instances to serve web traffic. It includes permissions to create and manage Elastic Load Balancers (ELB), which are used to distribute incoming traffic to your application across multiple EC2 instances.
AWSElasticBeanstalkWorkerTier: This policy is used for worker environments in Elastic Beanstalk, which are used for background processing or tasks that don't require direct handling of web requests. It provides permissions needed for worker environments, such as reading from and writing to SQS queues.
AWSElasticBeanstalkMulticontainerDocker: This policy is specifically for multicontainer Docker environments in Elastic Beanstalk. It provides permissions for managing Docker containers and interacting with the Docker daemon on the EC2 instances.

By attaching these policies to the IAM role associated with your EC2 instances, Elastic Beanstalk can manage the resources (such as ELBs and Docker containers) required to run your application. This allows Elastic Beanstalk to automatically scale your application, handle load balancing, and manage the underlying infrastructure, making it easier to deploy and manage your application in a scalable and fault-tolerant manner.

AWS provides several predefined roles that you can use for common tasks and services. These predefined roles are known as AWS managed policies. In our case, AWS already has a role for Elastic Beanstalk called aws-elasticbeanstalk-service-role. You may select this role and add the above three permissions.

When creating the role, here are the options you can select:

You may now navigate to the Elastic Beanstalk console and click on create new application. This will take you through a series of steps in creating the application.

Step 1:

We will use a Web Server environment since the aim is to deploy a sample web application

Next, an environment name will be generated for you. You may also enter a domain name, otherwise, it will be automatically generated for you.

Here, we select the appropriate configurations for the application we aim to run. In our case, since we are deploying a dockerized react application, we will choose docker.

We will start by deploying the sample application given to us by AWS, then modify it to our application.

Step 2:

This step has to do with IAM roles that will give elastic beanstalk the appropriate permissions to set up and run our application with the appropriate permissions. Here, under existing service roles, we will select the IAM role we made previously for Elastic Beanstalk.

Even though Elastic Beanstalk is setting up and managing the environment, it is possible to log into your EC2 once it’s running. You can create the EC2 key pair and specify it under the EC2 pair.

For the EC2 instance profile, you may create a role for the EC2 instances and select it here (Give it a try!).

Step 3

The next section is about setting up some network and database configurations.

You may select the VPC and the subnets that you want your instances to run in.

Since we will not be using a database for this application, we can leave it as disabled.

For Step 4 and 5, you may configure the instance traffic settings and monitoring and logging as desired.

After reviewing and creation, you may view the running instance of you web application through the given url:

Configuring Github Actions

To configure Github actions as needed, we can use instructions from this repo.

Essentially, your deploy yaml file will look something like this:

To configure the environment variables navigate to your repository’s settings tab > actions

Then create new repository secrets for the keys preceded with the word "secret" in the image above.

Under actions, add the Repository secrets:

After this, push the changes to your github.

git add .
git commit -m "commit message"
git push

After pushing the changes, you will see a new action triggered.

Once the environment is fully updated and set up on your elastic beanstalk, you should see the todo application deployed.

Congratulations on your first deployment!

Conclusion:

In summary, deploying a ReactJS application on AWS Elastic Beanstalk using GitHub Actions simplifies deployment and enhances application lifecycle management efficiency. GitHub Actions' integration automates build and deployment steps, ensuring consistency and enabling rapid, reliable releases. AWS Elastic Beanstalk provides scalability and managed environments, allowing seamless application scaling based on demand. This combination offers a robust solution for deploying and maintaining ReactJS applications, empowering developers to focus on delivering exceptional user experiences while ensuring deployment reliability and scalability.

Stay tuned for more deployment tutorials!

Introduction To AWS Elastic Beanstalk

Ednah — Sat, 09 Mar 2024 00:04:24 +0000

AWS Elastic Beanstalk is a Platform as a Service (PaaS) offering from Amazon Web Services (AWS) that makes it easy to deploy, manage, and scale web applications and services. It abstracts away the underlying infrastructure details and automatically handles the deployment of a web application, from capacity provisioning, load balancing, auto-scaling to application health monitoring. This allows developers to focus on writing code rather than managing underlying infrastructure.

At the same time, you retain full control over the AWS resources that are powering your application and can access them at any time. While it abstracts away the complexity of managing infrastructure, it still allows you to retain full control over the underlying AWS resources powering your application. This is important for several reasons:

Flexibility: By retaining control over the AWS resources, you have the flexibility to customize and configure them according to your specific requirements. You can choose the instance types, storage options, networking configurations, and other settings that best suit your application.
Performance Optimization: Full control over AWS resources allows you to optimize performance by fine-tuning configurations. For example, you can adjust instance sizes, add caching layers, or configure load balancers to improve performance and scalability.
Cost Management: Having visibility and control over AWS resources helps you manage costs more effectively. You can monitor resource usage, identify cost drivers, and make adjustments to optimize cost-efficiency.
Compliance: Some industries or organizations may have specific compliance requirements that necessitate full control over resources. With Elastic Beanstalk, you can ensure compliance by configuring resources according to these requirements.

It's worth emphasizing that using Elastic Beanstalk does not incur any extra costs. Instead, you only pay for the AWS resources required to store and operate your applications. You can learn more about its pricing here.

Reviewing some concepts

Application: In Elastic Beanstalk, an application is a logical container for your web application and its associated resources. Think of it as a folder. It helps you manage and organize your application components, including environments, versions, and configurations.

Environment: An environment is a collection of AWS resources that run your application. This includes EC2 instances, load balancers, databases, and other resources necessary to host your application. Each environment corresponds to a specific version of your application.

Environment Tier: Elastic Beanstalk offers two environment tiers:

Image Credit: Digital Cloud

Web Server Environment: This tier is used for web applications that serve HTTP requests. It typically includes a load balancer to distribute traffic among multiple EC2 instances running your application.
Worker Environment: This tier is used for applications that perform background tasks, such as processing messages from a queue or performing batch jobs. It does not include a load balancer and is optimized for tasks that do not require direct user interaction.

Application Version: An application version is a specific iteration of your application's code that you deploy to an environment. Each version is identified by a unique version label and can be deployed to multiple environments.

Configuration: Elastic Beanstalk allows you to configure various aspects of your environment through configuration files or the management console. This includes settings such as instance type, auto-scaling parameters, environment variables, and more. Configurations can be saved and reused across environments.

Auto Scaling: Elastic Beanstalk provides auto-scaling capabilities to automatically adjust the number of EC2 instances in your environment based on traffic levels. You can define scaling triggers based on metrics such as CPU utilization, network traffic, or custom metrics.

Environment Health: Elastic Beanstalk monitors the health of your environment and takes corrective actions to ensure high availability. This includes replacing unhealthy instances, adjusting auto-scaling settings, and triggering alarms based on predefined thresholds.

Steps to deploy a sample Python application

Now that we know some basics, let's try to deploy a sample application. Navigate to the Elastic Beanstalk console and create new application.

After this, on the left sidebar, you will see the application created. Click on the application.

Then Click on create new environment at the top right. You will then run through a series of steps, instructing Beanstalk on how to build our web application.

You will need to configure you environment based on the web application that you want to deploy. Elastic Beanstalk supports a wide range of web applications and frameworks including Java ( using Apache Tomcat, Java SE, or Java with Docker containers), .NET (using IIS and Windows Server), Nodejs, PHP, Python, Ruby, Go, and last but no least Docker (supports applications packaged as Docker containers, allowing you to use any language, framework, or runtime that can run in a container).

Since our aim is to deploy a sample python web application, we will use a Web Server environment.

Next, you can choose an environment name or use the autogenerated one. You may also enter a domain name or use one that will be autogenerated.

Next, we will choose the python version that we want to use. You may choose the appropriate version for your application. For this demo, we will use the latest versions available.

We then select the application we want to deploy. At the moment, since we don’t have code, we can deploy the sample application, which we can change at a later stage to the python application we want.

The next section, Service access, has to do with IAM roles that will give elastic beanstalk the appropriate permissions to set up and run our application with the appropriate permissions.
Even though Elastic Beanstalk is setting up and managing the environment, it is possible to log into your EC2 once it’s running. You can create the EC2 key pair and specify it here. Since I had created an application on elastic beanstalk, I already have some roles defined that can be used. You may choose the “Create and use new service role” to create roles as needed.

The following section covers network and database configurations. You can select the Virtual Private Cloud (VPC) and the specific subnets where you want your instances to run.

Next, should your application need a database, you might need to configure some database settings. Since ours doesn’t at the moment, we can skip this part. Should you need a database, toggle the option to enable, choose the subnets you want it to be deployed to, and update the settings such as the Engine you want, instance class of the compute that will run your database, the amount of storage you need and configure your database credentials as well.

At step 4, you will configure more aspects of the EC2 instances that run your application. These aspects include The number of gigabytes of the root volume attached to each instance, Input/output operations per second for a provisioned IOPS (SSD) volume, the amount of throughput desired, security groups (you can choose the default or create your own) and configure CloudWatch monitoring as well.

You can also configure the compute capacity of your environment and specify aspects such as the environment type, number of instances you need among other settings based on your needs.

In the next tab, you can configure various monitoring and logging aspects of your application. You can then review your settings and create the environment

Once you click on create, you can monitor the events that are happening on the dashboard of your environment.

After a while the environment will launch successfully

You may visit the url for your deployed application

With our simple Python application now successfully deployed on Elastic Beanstalk, our next step involves exploring the deployment of a Dockerized container. This will further enhance our understanding and utilization of Elastic Beanstalk's capabilities, allowing us to leverage containerization for our application deployment in future articles.