Sitemap

Docker and GitHub Action

18 min readSep 3, 2022

--

Press enter or click to view image in full size
Picture 1: Docker and GitHub Action (https://lab.github.com/githubtraining/github-actions:-write-docker-container-actions)

Hajimemashite, mediumers!!!

In this article, I will discuss Docker and GitHub Action from their understanding, components, and how to implement them in the technology world. Here’s a summary.

1. Docker

Docker is a set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers. Containers are isolated from one another and bundle their own software, libraries, and configuration files; they can communicate with each other through well-defined channels. All containers are run by a single operating-system kernel and are thus more lightweight than virtual machines. Docker, for example, allows the WordPress content management system to run flawlessly on Windows, Linux, and macOS systems.

Docker Container

Docker Container is a standardized unit that can be created on the fly to deploy a particular application or environment. It could be an Ubuntu container, CentOs container, etc. to fulfill the requirement from an operating system point of view. Also, it could be an application-oriented container like a CakePHP container or a Tomcat-Ubuntu container, etc.

Picture 2: Docker Containers

Container management is simple with the Docker API or command-line interface (CLI). If multiple containers are required, the Docker compose tool can be used to manage them. Using Docker containers saves users the hassle of troubleshooting possible compatibility issues between systems. That’s because, with Docker, a piece of software runs the same in all environments.

Docker Concepts

Docker is a platform for developers and sysadmins to build, share, and run applications with containers. The use of containers to deploy applications is called containerization. Containers are not new, but their use for easily deploying applications is.

Containerisation is increasingly popular because containers are:

  • Flexible: Even the most complex applications can be containerized.
  • Lightweight: Containers leverage and share the host kernel, making them much more efficient in terms of system resources than virtual machines.
  • Portable: You can build locally, deploy to the cloud, and run anywhere.
  • Loosely coupled: Containers are highly self-sufficient and encapsulated, allowing you to replace or upgrade one without disrupting others.
  • Scalable: You can increase and automatically distribute container replicas across a data center.
  • Secure: Containers apply aggressive constraints and isolations to processes without any configuration required on the part of the user.
Picture 3: How Docker Containers running

Docker and Virtual Machine

While Docker and virtual machines serve similar functions, they differ significantly in terms of performance, OS support, and portability.

The primary distinction is that Docker containers share the host’s operating system, whereas virtual machines run a guest operating system on top of the host system. This mode of operation has an impact on performance, hardware requirements, and OS support. A detailed comparison can be found in the table below.

Picture 4: Docker and Virtual Machine

A container runs natively on Linux and shares the kernel of the host machine with other containers. It runs a discrete process, taking no more memory than any other executable, making it lightweight.

By contrast, a virtual machine (VM) runs a full-blown “guest” operating system with virtual access to host resources through a hypervisor. In general, VMs incur a lot of overhead beyond what is being consumed by your application logic.

lets me summarise the learning till now:

  • Virtual Machines are slow and take a lot of time to boot.
  • Containers are fast and boot quickly as it uses the host operating system and shares the relevant libraries.
  • Containers do not waste or block host resources, unlike virtual machines.
  • Containers have isolated libraries and binaries specific to the application they are running.
  • Containers are handled by the Containerisation engine.
  • Docker is one of the containerization platforms which can be used to create and run containers.
  • Unlike VMs( Virtual Machines ) that run on a Guest OS, using a hypervisor, Docker containers run directly on a host server (for Linux), using a Docker engine, making it faster and lightweight.
  • Docker containers can be easily integrated compared to VMs.
  • With a fully virtualized system, you get more isolation. However, it requires more resources. With Docker, you get less isolation. However, as it requires fewer resources, you can run thousands of containers on a host.
  • A VM can take a minimum of one minute to start, while a Docker container usually starts in a fraction of a second.
  • Containers are easier to break out of than a Virtual Machine.
  • Unlike VMs there is no need to preallocate the RAM. Hence docker containers utilize less RAM compared to VMs. So only the amount of RAM that is required is used.
Press enter or click to view image in full size
Picture 5: Comparison of using Docker and Virtual Machine
Press enter or click to view image in full size
Picture 6: Comparison of using Docker and Virtual Machine

Docker and Kubernetes

While Docker is a container runtime, Kubernetes is a platform for running and managing containers from many container runtimes. Kubernetes supports numerous container runtimes including Docker, containers, CRI-O, and any implementation of the Kubernetes CRI (Container Runtime Interface). A good metaphor is Kubernetes as an “operating system” and Docker containers are “apps” that you install on the “operating system”.

On its own, Docker is highly beneficial to modern application development. It solves the classic problem of “works on my machine” but then nowhere else. The container orchestration tool Docker Swarm is capable of handling a production container workload deployment of a few containers. When a system grows and needs to add many containers networked to each other, standalone Docker can face some growing pains that Kubernetes helps address.

When comparing the two, a better comparison is of Kubernetes with Docker Swarm. Docker Swarm, or Docker swarm mode, is a container orchestration tool like Kubernetes, meaning it allows the management of multiple containers deployed across multiple hosts running the Docker server. Swarm mode is disabled by default and is something that needs to be set up and configured by a DevOps team.

Kubernetes orchestrates clusters of machines to work together and schedules containers to run on those machines based on their available resources. Containers are grouped together, through declarative definition, into pods, which is the basic unit of Kubernetes. Kubernetes automatically manages things like service discovery, load balancing, resource allocation, isolation, and scaling your pods vertically or horizontally. It has been embraced by the open-source community and is now part of the Cloud Native Computing Foundation. Amazon, Microsoft, and Google all offer managed Kubernetes services on their cloud computing platforms, which significantly reduces the operational burden of running and maintaining Kubernetes clusters and their containerized workloads.

Press enter or click to view image in full size
Picture 6: Docker and Kubernetes
Press enter or click to view image in full size
Picture 7: Comparison Using of Docker and Kubernetes

So if both Docker Swarm and Kubernetes are container orchestration platforms, which do you choose?

Docker Swarm typically requires less setup and configuration than Kubernetes if you’re building and running your own infrastructure. It offers the same benefits as Kubernetes, like deploying your application through declarative YAML files, automatically scaling services to your desired state, load balancing across containers within the cluster, and security and access control across your services. If you have few workloads running, don’t mind managing your own infrastructure, or don’t need a specific feature Kubernetes offers, then Docker Swarm may be a great choice.

Kubernetes is more complex to set up in the beginning but offers greater flexibility and features. It also has wide support from an active open source community. Kubernetes supports multiple deployment strategies out of the box, can manage your network ingress, and provides observability out of the box into your containers. All major cloud vendors offer managed Kubernetes services that make it significantly easier to get started and take advantage of cloud-native features, like auto-scaling. If you are running many workloads and require cloud-native interoperability, and have many teams in your organization, which creates the need for greater isolation of services, then Kubernetes is likely the platform you should consider.

2. How to Docker Work?

Along with Docker containers, which we discussed earlier, the Docker architecture consists of four main components.

  • Docker client — the primary component for developing, managing, and running containerized applications. The Docker client is the primary means of controlling the Docker server via a command line interface (CLI) such as Command Prompt (Windows) or Terminal (macOS, Linux).
  • Docker server — also known as the Docker daemon. It manages images and containers while waiting for REST API requests from the Docker client.
  • Docker images — provide instructions to the Docker server on how to create a Docker container. Images can be obtained from websites such as Docker Hub. It is also possible to create a custom image; to do so, users must create a Dockerfile and pass it to the server. It’s worth noting that Docker doesn’t remove any unused images, so users must delete image data before there’s too much of it.
  • Docker registry — an open-source server-side application for hosting and distributing Docker images. The registry is particularly useful for storing images locally while maintaining complete control over them. Users can also go to the aforementioned Docker Hub, which is the world’s largest repository of Docker images.

Let’s talk about the functioning of Docker. Docker has a docker engine, which is the heart of the Docker system. It is a client-server application. It has three main components:

  • A server is a type of long-running process called a daemon process.
  • A client which is Docker CLI( Command Line Interface), and
  • A REST API is used to communicate between the client( Docker CLI ) and the server ( Docker Daemon )

The Docker daemon receives the command from the client and manages Docker objects, such as images, containers, networks, and volumes. The Docker client and daemon can either run on the same system, or you can connect a Docker client to a remote Docker daemon. They can communicate using a REST API, over UNIX sockets, or a network interface.

In Linux, the Docker host runs the docker daemon and the docker client can be accessed from the terminal.

In Windows/OS X, there is an additional tool called the Docker toolbox. This toolbox installs the docker environment on Win/OS system. This toolbox installs the following: Docker Client, Compose, Kitematic, Machine, and Virtual Box

Press enter or click to view image in full size
Picture 8: Docker Functioning on OS

Technology Used in Docker

The programming language used in Docker is GO. Docker takes advantage of various features of the Linux kernel namespaces and cgroups.

a. namespaces

Docker uses namespaces to provide an isolated workspace called containers. When a container is run, docker creates a set of namespaces for it, providing a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace.

b. cgroups ( control groups ):

Cgroups are used to limit and isolate the resource usage( CPU, memory, Disk I/O, network, etc ) of a collection of processes. cgroups allow Docker engine to share the available hardware resources to containers and optionally enforce limits and constraints.

c. UnionFS ( Union file systems )

UnionFS are file systems that operate by creating layers, making them very lightweight and fast. It is used by the Docker engine to provide the building blocks for containers. Docker Engine combines the namespaces, cgroups, and UnionFS into a wrapper called a container format. The default container format is libcontainer.

Docker Use Cases

Docker has numerous applications. In this section, we’ll look at three common Docker use cases and explain how they can help you.

  • Docker allows you to test new software without having to install it manually. Docker is also useful when you need a piece of software to be ready quickly. Setting up a MySQL server, for example, is a time-consuming and labor-intensive process. It only takes one command in the Docker CLI to a
  • Although Docker can run on any machine, it was designed primarily for Linux. As a result, we recommend installing it on a Linux-based system. It will give you a great chance to learn more about system administration, command-line interfaces, and scripting.
  • If a Docker image is available, users can quickly undo any changes in the event of a hardware failure. They only need to copy the image backup to a new machine, and Docker will take care of the rest. Docker image backups are also useful when developers need to revert to an earlier version of a piece of software due to bugs or incompatibility.

3. Install Docker Desktop

The best way to get started developing containerized applications is with Docker Desktop, for OSX or Windows. Docker Desktop will allow you to easily set up Kubernetes or Swarm on your local development machine, so you can use all the features of the orchestrator you’re developing applications for right away, no cluster required. Follow the installation instructions appropriate for your operating system:

Docker Daily use commands:

a. docker –version

This command is used to get the currently installed version of docker

b. docker pull

Usage: docker pull <image name>. This command is used to pull images from the docker

c. docker run

Usage: docker run -it -d <image name>. This command is used to create a container from an image

d. docker ps

This command is used to list the running containers

e. docker ps -a

This command is used to show all the running and exited containers

f. docker exec

Usage: docker exec -it <container id> bash. This command is used to access the running container

g. docker stop

Usage: docker stop <container id>. This command stops a running container

h. docker kill

Usage: docker kill <container id>. This command kills the container by stopping its execution immediately. The difference between ‘docker kill’ and ‘docker stop’ is that ‘docker stop’ gives the container time to shutdown gracefully, in situations when it is taking too much time for get the container to stop, one can opt to kill it

i. docker commit

Usage: docker commit <conatainer id> <username/imagename>. This command creates a new image of an edited container on the local system

j. docker login

This command is used to log in to the docker hub repository

k. docker push

Usage: docker push <username/image name>. This command is used to push an image to the docker hub repository

l. docker images

This command lists all the locally stored docker images

m. docker rm

Usage: docker rm <container id>. This command is used to delete a stopped container

n. docker rmi

Usage: docker rmi <image-id>. This command is used to delete an image from local storage

o. docker build

Usage: docker build <path to docker file>. This command is used to build an image from a specified docker file

4. Implementation

Let's say we have a PHP application and want to deploy it to our staging or production server. First, we make sure we have the docker configuration script included in the root directory of the application.

Get Febry Heri Setiyawan’s stories in your inbox

Join Medium for free to get updates from this writer.

Create a Dockerfile in your application

Create a file with the name Dockerfile at the root of your application and include the code below to tell docker what to do when running in the production or staging environment

FROM PHP:7.2-Apache
COPY src/ /var/www/html/
EXPOSE 80

Above is a sample docker script that configures PHP version 7.2 on a staging or production server, and copies the PHP files from /src directory to /var/www/html/ and expose port 80 to be reached.

Installing Docker on Staging Or Production Server

For Mac get docker here.

For Windows go here.

Running Docker

After docker is installed on the staging or production server, click on the whale icon to run docker

Deploying Your Application

Copy the application to the staging or production server and do the following

  • Navigate to the project directory on the terminal and create a docker image.

Run the following command in the terminal and it will create a docker image of the application and download all the necessary dependencies needed for the application to run successfully

docker build -t <name to give to your image>
  • Convert the Docker image of the Application into a Running container.

Run the following command in the terminal and it will use create a running container with all the needed dependencies and start the application.

docker run -p 9090:80 <name to give to your container>

The 9090 is the port we want to access our application on. 80 is the port the container is exposing for the host to access.

Below are some useful Docker commands

Stopping a running image

docker stop <id-of-image>

Starting an image that is not running

docker start <id-of-image>

Removing an image from docker

docker rmi <id-of-image>

Removing a container from docker

docker rm <id-of-container>

5. Docker Orchestration

Press enter or click to view image in full size
Picture 9: DockerOrchestration https://codeblog.dotsandbrackets.com/docker-stack/)(

Container orchestration is the automatic process of managing or scheduling the work of individual containers for applications based on microservices within multiple clusters. The widely deployed container orchestration platforms are based on open-source versions like Kubernetes, Docker Swarm, or the commercial version from Red Hat OpenShift. The Docker container orchestration tool, can package and run applications as containers, find existing container images from others, and deploy a container on a laptop, server, or cloud (public cloud or private). Docker container orchestration requires one of the simplest configurations.

Why Do We Need Container Orchestration?

Container orchestration is used to automate the following tasks at scale:
• Configuring and scheduling containers
• Provisioning and deployments of containers
• Availability of containers
• The configuration of applications in terms of the containers that they run in
• Scaling of containers to equally balance application workloads across infrastructure
• Allocation of resources between containers
• Load balancing, traffic routing, and service discovery of containers
• Health monitoring of containers
• Securing the interactions between containers.

How Does Container Orchestration Work?

Press enter or click to view image in full size
Picture 10: Docker Orchestration’s Work

Container orchestration works with tools like Kubernetes and Docker Swarm. Configuration files tell the container orchestration tool how to network between containers and where to store logs. The orchestration tool also schedules the deployment of containers into clusters and determines the best host for the container. After a host is decided, the orchestration tool manages the lifecycle of the container based on predetermined specifications. Container orchestration tools work in any environment that runs containers.

Orchestration tools for Docker include the following:
• Docker Machine — Provisions hosts and installs Docker Engine.
• Docker Swarm — Clusters multiple Docker hosts under a single host. It can also integrate with any tool that works with a single Docker host.
• Docker Compose — Deploys multi-container applications by creating the required containers.

Orchestration tools for Kubernetes include the following features:
• Automated deployment and replication of containers.
• Online scale-in or scale-out of container clusters.
• Load balancing groups of containers.
• Automated rescheduling of failed containers.
• Controlled exposure of network ports to systems outside of the cluster.

Benefits of Containerized Orchestration Tools

• Increased portability — Scale applications with a single command and only scale specific functions without affecting the entire application.
• Simple and fast deployment — Quickly create new containerized applications to address growing traffic.
• Enhanced productivity — Simplified installation process and decreased dependency errors.
• Improved security — Share specific resources without risking internal or external security. Application isolation improves web application security by separating each application’s process into different containers.

Docker Container Orchestration vs. Kubernetes Container Orchestration

The Docker container orchestration tool, also known as Docker Swarm, can package and run applications as containers, find existing container images from others, and deploy a container on a laptop, server or cloud (public cloud or private). Docker container orchestration requires one of the simplest configurations.

Orchestration in container services for Kubernetes allows container clustering via a container orchestration engine. Kubernetes has declarative management that hides complexity and is open source so you can run it anywhere.

Does Avi Integrate with Container Orchestration?

Avi provides a centrally orchestrated, ingress gateway for containers composed of a fabric of proxy services with dynamic load balancing, service discovery, security, micro-segmentation, and analytics for container-based applications running in OpenShift and Kubernetes environments.

Avi Networks delivers a scalable, enterprise-class Container Ingress to deploy and manage business-critical workloads in production environments using Redhat container orchestration with OpenShift and Kubernetes clusters.

6. Github Action

Press enter or click to view image in full size
Picture 11: Github Action

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository or deploy merged pull requests to production.

GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

The components of GitHub Actions

You can configure a GitHub Actions workflow to be triggered when an event occurs in your repositories, such as a pull request being opened or an issue being created. Your workflow contains one or more jobs that can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

Press enter or click to view image in full size
Picture 12: GitHub Action Workflow

Workflows

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.

Workflows are defined in the .github/workflows directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.

You can reference a workflow within another workflow, see “Reusing workflows.”

Events

An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from GitHub when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow run on a schedule, by posting to a REST API, or manually.

For a complete list of events that can be used to trigger workflows, see Events that trigger workflows.

Jobs

A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.

You can configure a job’s dependencies with other jobs; by default, jobs have no dependencies and run in parallel with each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run. For example, you may have multiple build jobs for different architectures that have no dependencies, and a packaging job that is dependent on those jobs. The build jobs will run in parallel, and when they have all completed successfully, the packaging job will run.

For more information about jobs, see “Using jobs.”

Actions

An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.

You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.

For more information, see “Creating actions.”

Runners

A runner is a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine. GitHub also offers larger runners, which are available in larger configurations. For more information, see “Using larger runners.” If you need a different operating system or require a specific hardware configuration, you can host your own runners. For more information about self-hosted runners, see “Hosting your own runners.”

For more information about workflows, see “Using workflows.”

That’s the explanation about Docker and GitHub Action that I got at the ninth meeting of Aqua Developer, eFishery Academy. If there are criticisms and suggestions, they can be written in the comments column in the medium. That is all and thank you.

Ref:

eFishery presentation material, accessed on September 3rd, 2022

https://myhistoryfeed.medium.com/docker-explained-cfff1df64dd9, accessed on September 3rd, 2022

https://docker-curriculum.com/#why-use-containers-, accessed on September 3rd, 2022

https://www.atlassian.com/microservices/microservices-architecture/kubernetes-vs-docker#:~:text=While%20Docker%20is%20a%20container,CRI%20(Container%20Runtime%20Interface)., accessed on September 3rd, 2022

https://medium.com/@kmdkhadeer/docker-get-started-9aa7ee662cea, accessed on September 3rd, 2022

https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action, accessed on September 3rd, 2022

https://avinetworks.com/glossary/container-orchestration/#:~:text=The%20Docker%20container%20orchestration%20tool,one%20of%20the%20simplest%20configurations., accessed on September 3rd, 2022

https://docs.docker.com/get-started/orchestration/, acessed on September 3rd, 2022

https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions, accessed on September 3rd, 2022

--

--