Docker is a containerization platform that helps develop, deploy, and manage applications in isolated environments. Docker also makes it easy to share code between machines with the capability of deploying software on any machine without changing underlying packaging systems or dependencies. In addition to securing your online presence by encrypting data before sending it across the Internet (to prevent tampering), you can use containers for more mundane tasks like managing versions of independent apps and backing up critical files from one location onto another.
“docker commit changes to same image” is a command that allows users to change the images of the containers. This can be useful for testing and debugging purposes.
Immutability is a key feature of Docker containers. You may delete and rebuild containers at any moment to restore the original state. You may commit new modifications to a container image using the docker commit command, but it’s not as simple as you would think.
Let’s look at how to use the docker commit command to commit changes to a new container image!
When Should Changes to a New Container Image Be Committed?
Why would you want to commit modifications to a container that is designed to be immutable (not changed)? There are many causes for this.
- To swiftly test modifications during the development of a new containerized service.
- Repair a production service’s problem quickly without having to first fix the source image.
- To take a snapshot of an image and export it to a different server, use commit.
Though this list does not include all possible cases, it does include a few that make docker commit an excellent choice.
Making Changes to a Basic Image
This command does a lot for what seems to be a basic command.
A basic commit command is shown below. A new image is produced in a repo called myrepository and titled changedimage, using a running container ID of d3fdd3517e0a in our case.
The original picture is labeled with version2, which is optional but helpful for tracking changes across photos with similar names.
Myrepository and changedimage are both picked at random, however they should represent correctly identified resources like customimages/alpine-linux.
myrepository/changedimage:version2 docker commit d3fdd3517e0a
Docker containers are made up of a read-only layer on top of a read-write layer. Docker pauses the operating container in the case above. While Docker produces the image, this wait serves to avoid unintentional data damage.
Because this pause may cause service disruptions, use —pause=false instead. Because writes may not finish properly, data may be corrupted.
Furthermore, data stored in volumes mounted inside the container is not committed. Docker ignores volumes because they are not part of the container’s file system.
Docker then builds a new layer with the modifications from the original image under the new container image name after the commit procedure is complete.
Prerequisites
The only need for this course is Docker. This may be installed on Windows using the Docker Desktop program or on Linux using a package.
Deploying Your First Docker Container on Windows is Related
Adding Modifications to a New Docker Container Image
Let’s look at several cases where the docker commit command might be useful.
To begin, download an Alpine Linux container image from the Docker public repository. Alpine is famed for its small containers, as the 5MB size indicates.
# Docker pull alpine to get the most recent Alpine Linux image # Get a list of all Docker images
Get a fresh alpine docker image
Development and Testing of Containers
The construction of a new container image is the most common use case for docker commit. This picture may be used as a foundation for subsequent photos or as the production container itself in the future.
Docker is defined as follows in the sample snippet below:
- Using the alpine picture that was previously extracted
- To install a package, open an interactive shell.
- htop package installation
# Run the Docker Alpine Linux container interactively using docker run -it a24bb4013296 bin/sh. # Download and install the HTOP package apk.
To the alpine container, add the HTOP package.
Using the htop command, you can observe if the package is appropriately installed in the container.
Check that HTOP is active.
You should now commit the update to the old base image after installing the package on the new “layer.” To do so, first:
- To get the container ID, use docker ps -a.
- Commit the content of the current layer to a new base image using the container ID.
The new picture is entitled alpine-htop and labeled version1 in the example below. The image is marked to make it easier to track down docker image variants with similar names.
# List all Docker containers, regardless of state, using -a or —all to see every docker container ps -a # Save the layer as alpine-htop:version1 in a new picture. # Get a list of all available Docker images.
Create a new Docker image using the HTOP application.
Production Image Bug Fixing
Occasionally, a production service will include a mistake. There may be a known patch that you may apply rather than altering and redeploying the old settings. You may rapidly apply the patch and then work in the background to update the remaining required components using docker commit.
Installing NGINX into an Alpine Linux Docker image is shown in the example below.
# To begin, make a list of all accessible images docker images # Docker run -it a24bb4013296 bin/sh # Interactive session for the alpine-htop image apk add nginx # Install the NGINX package mkdir /run/nginx # Create the location for the NGINX PID file. nginx -v # Verify that NGINX is installed NGINX # /usr/sbin/nginx Make that NGINX is up and running. grep nginx # ps # terminate the NGINX process Make sure the NGINX process isn’t running. grep nginx ps
Create a Docker container for Alpine NGINX.
Commit the newly generated NGINX container to a new image called alpine-nginx with the tag version1. Tagging a picture is a good way to distinguish between various versions of the same image.
# Use -a or —all to list all Docker containers, regardless of their state. docker ps -a # Commit the modifications to a new image called alpine-nginx:version1 docker commit 37043139525c # Make sure the new image was built using Docker.
In a new Docker container, commit the NGINX container images.
Not every executable, including NGINX, will be allowed to execute in the background. Pass the -g ‘daemon off;’ option to NGINX to correctly operate this container with NGINX operating in the background.
# Docker run -d f6b46a3b76be /usr/sbin/nginx -g ‘daemon off;’ # Docker run -d f6b46a3b76be /usr/sbin/nginx -g Check to see whether the container is using Docker. ps -a
In the background, run the NGINX process.
Finally, to expose port 80, use the —change switch. The EXPOSE 80 command will be written to the container’s DockerFile if the —change argument is used. Start the new container once you’ve made this adjustment. Following the start of the new container, halt the prior container that was running erroneously without the exposed port. This will aid in the smooth transition from the non-working to the operational container.
# docker list all running containers docker commit —change “EXPOSE 80” c649c813d985 alpine-nginx:version2 ps -a # Commit the modifications to a new image with an exposed port 80 docker commit —change “EXPOSE 80” # List the docker containers that are currently operating. ps -a # Get a list of all Docker images # Docker run -d c71f0f9cef7b /usr/sbin/nginx -g ‘daemon off;’ to execute the freshly built image # List running Docker containers ps -a # Docker shutdown the previous container without the exposed port 80 c649c813d985 # docker ps -a list of running containers
Create a new NGINX image that uses port 80.
Taking a Docker Image Snapshot
Finally, what if you need to take a snapshot of a running container in order to transfer it to a different server? As seen below, the docker commit command works nicely for this.
The instructions below start a container that we will stop and upgrade to a new version of alpine-nginx.
# List of Docker containers in use docker ps -a # Run docker run -d c71f0f9cef7b to start a new Docker NGINX container. # List of Docker containers in use docker ps -a # Docker container shutdown docker shutdown 7ff99f2bcf6b # Export docker commit 7ff99f2bcf6b by creating a new alpine-nginx version. alpine-nginx:version3 # List the Docker images that are currently accessible.
Create a new NGINX Docker image for Alpine Linux.
Create a file from the Docker image. The export file is called export.tar in this example, but you may name it anything you like. Finally, import the export.tar file into Docker to complete the demonstration.
If you want the labels to stay when you re-import the picture, be sure you export using the repo:tag format.
# Docker save -o export.tar alpine-nginx:version3 # Make sure the picture exists ls # Delete the Docker image that was just exported using docker rmi 39ca9e64828a. # Check to see whether any Docker images have been deleted. images docker # Use docker load -i export.tar to reload the Docker image. Show that the image has been loaded back into Docker images by listing Docker images.
Export a picture and then import it again
Additional Docker Commit Command Options
Many different circumstances may be accommodated by using the commit command’s extra arguments.
Container Interruption
You may deactivate the pausing functionality by passing in the —pause=false command while the container is executing. When backing up a production service and interrupting it might be hazardous, this is often employed.
The pause command has a shortcut of -p that may be more convenient. However, by skipping the container’s pause, you risk data corruption if a filesystem write is in progress, which might result in incomplete or corrupt data being written.
Leaving a Message of Commit
Many developers are familiar with the importance of choosing the correct commit message. You should preferably deliver a meaningful message that describes why a new version of the container was committed, much as when using source control.
The —message=”message to commit” command may be used to do this. This command has a shorthand variant, -m, as previously. Use the docker history command to view a list of Docker commit messages.
Author Identification
You may supply an author value to appropriately designate who is making the change. This will offer some further context to who is making the modification. The —author=”Jane Author ([email protected])” option may be used to do this. This command may also be used with the -a shortcut. You may get a JSON listing of container metadata, including labels like author, by using docker inspect.
Changes to DockerFile are applied in parallel.
Finally, the change parameter is the most difficult command available in the docker commit command. At the same time as the commit, this option applies changes in the container to the DockerFile.
The change option may be used by supplying instructions to the Dockerfile, such as —change=”ENV TEST true.” The text ENV TEST true is written to the DockerFile with this command. When the container starts up again, the modifications you specify here will already be in effect.
Instead of using the —change name option, you may use the -c alias.
You may also use this command to link several —change parameters together. This makes it simple to make many changes to a DockerFile with just one commit command.
Options for Changing Parameters
With the change parameter, you can only use a few instructions, as illustrated below.
- CMD – The CMD command is written as [“executable”,”parameter1″,”parameter2″]. This is the recommended option, however bear in mind that each DockerFile can only have one CMD. The CMD that takes effect will be the final one. CMD’s main function is to give default execution commands for containers when they are created.
- ENTRYPOINT – ENTRYPOINT [“executable”,”parameter1″,”parameter2″] utilizes the same syntax as the CMD command. Why use ENTRYPOINT instead than CMD, given this syntax?
The ENTRYPOINT command launches a program as PID 1’s principal process. This enables you to gracefully shut down the process using docker stop. You may also use CMD with this by omitting the executable component that gives the arguments to the ENTRYPOINT program.
- ENV — Because most programs use environmental variables, the ENV command makes it easy to set them in the key-value format of ENV key=value. These key=value variables may be accessed as regular Linux environment variables.
- EXPOSE – The EXPOSE command allows you to expose a port and optional protocol to the outside world. This command maps ports within the container to ports outside the container, allowing containers to communicate with external resources like a web server supplying content.
- The LABEL command is used to add metadata to a container. The format LABEL version=”2.0″ may be used to add metadata, and the docker image inspect command can be used to display the added information.
- ONBUILD — When the image is used as a foundation for another container build, the ONBUILD command adds an instruction to run later. This argument adds material with the ADD command or runs an executable with the RUN command.
- The USER command specifies the user name (or UID) and, if desired, the user group (or GID) to be used while executing the image. In practice, this seems to be USER myuser:mygroup.
- VOLUME – Data must be accessed in some manner with most containers. The VOLUME command creates a mount point with a name that identifies it as containing an externally mounted volume. VOLUME [“/data”] is an example of how this is typically used.
- Finally, the WORKDIR command is used to establish the working directory for the CMD and ENTRYPOINT commands. WORKDIR /path/to/directory is how it’s done. When you need to start an executable that isn’t in the usual PATH environment variable, WORKDIR comes in handy.
Conclusion
The commit command in Docker is quite complicated. With the ability to add DockerFile modifications while using the commit command, you may rapidly make changes that will survive when the container is created again using the DockerFile.
This command may not be required in all scenarios, but it is very handy for rapid troubleshooting and snapshot containers that can be simply transferred across servers!
The “docker commit vs save” is a command-line tool that allows users to change the container images. The “docker commit” takes a new image, while the “save” saves an image to a file.
Related Tags
- docker commit and push
- docker save container as image
- docker commit stackoverflow
- edit dockerfile of pulled image
- docker run and commit
