Given our affinity for Docker, we wanted to pass along some tips and best practices for using it at the command-line. To do that we’ve created a convenient Docker Commands Cheat Sheet to help improve your work flow. Now, you can avoid having to search for these shortcuts every time you open the software. Neat, right?
For those who are relatively new to container technology, Docker’s complexity lies in its diffuse set of commands. Once you understand the basic structure, leveraging the command-line is straightforward.
Docker Commands Basic Structure:
It’s useful to understand the structure and syntax of a Docker command to execute them properly. By adhering to this best practice format, you should then always get your desired results.
To begin, here are some of the key terms you’ll come across when using Docker.
- Image — A snapshot file of a container. Create containers by pulling and running Docker Images.
- Docker Hub / Registry — A public cloud-based registry service for developers to share their code on.
- [options] — Add options to your Docker commands to change the results. Each command has multiple options available.
- [command] — Enter the parameters for the Docker command, this could be a filename or container ID.
- [arg] — Set additional argument variables.
- [env] — Use to configure environment variables.
- [init] — Initialize a swarm (by default, Docker will designate chosen machine as manager node).
- [ca] — Show root Certificate Authority (auto-generated by init command).
- [join] — Join a swarm as a worker/manager node.
- [join-token] — Manage join tokens—define worker or manager accordingly.
- [leave] — When implemented on a worker, the command prompts the node to leave the swarm.
- [–force] — When implemented on a manager, the command forces the node to leave the swarm.
- [tag] — The tag parameter is often part of the image name, but as your swarm develops you can adjust the tag without changing the base image name.
- [unlock] — Unlock swarm manager with a user-own unlock key.
- [unlock-key] — Manage the unlock key, useful to unlock a manager node.
- [update] — Update the swarm.
Let’s put some of these key terms into context.
This is often one of the first commands everyone learns when they begin using Docker. Initiating ‘docker run’ will create and start a container in the same operation—where ‘docker create’ only builds a container and needs further ‘start’ and ‘stop’ requests made to get it running.
Furthermore, if you want to keep your container running you need to specify that, so use the command:
docker run –name container_name docker_image
Referencing the ‘–name’ allows you to start and stop the container specifically.
Other useful flags to attach to the ‘docker run’ command are:
- -d — Detach container on start
- -rm — Remove container once it stops
- -p — Publish host IP and host port to the container port (e.g. docker run host_ip:host_port:container_port)
- -v — Define volume mounts to share storage volume across containers
- –read-only — Sets container to be read-only
Initialize the swarm by logging into your lead server and automatically designating it manager status:
docker swarm init –advertise-addr server_ip_address
Each manager node automatically creates a new root Certificate Authority (CA) with a key pair. On top of that, using the command auto-generates a worker node token to enable other machines to join the swarm.
Paste the worker token you receive into other servers to join the swarm as worker nodes. For an in-depth guide to this process, read our post on Creating a High-Availability Docker Swarm on AWS
If you lose this token at any time, just SSH back into a manager server and run:
docker swarm join <worker> token
To get the manager join command:
docker swarm join <manager> token
To view the status of nodes within a swarm:
docker node ls
To view all running swarms:
docker stack ls
With those basics out the way, it’s worth knowing how to promote a worker node to manager status. Get the ‘node_name’ from the Docker node list and use:
docker node promote node_name
Let’s build! A Docker container is essentially a set of processes running in contained isolation with a preconfigured file system attached. Put simply, a container is a collection of processes that have access to the same files in the image.
Docker images are all publicly available. They do perform within a hierarchy, so images will have certain dependencies on others. To pull an image from the Registry, define the image_name and use the command:
docker pull image_name:tag
To build an image from your Dockerfile:
docker build -t image_name:tag
The ‘-t‘ flag tags the image with a helpful repository name and tag.
If you don’t want your container to autostart, as with the ‘run’ command, use:
docker create –name container_name image_name:tag
Establish the ‘–name’ criteria at this point, or by default, Docker will assign one for you. Naming makes it easy for you to reference the container when executing commands. Now use:
docker start container_name
docker stop container_name
These commands will start and stop the container use respectively. For every stop command, there’s also a more forceful ‘kill’ version too which will end the process with a lot less grace.
A service is defined as a group of containers with the same ‘image:tag‘, and a collection of services is known as a stack. Creating and adapting services allows you to scale your application.
Note: Before deploying a service, you need to have at least one node running.
To view a list of all the services running in a swarm:
docker service ls
To see all running services:
docker stack services stack_name
To go in depth into a stack and see all service logs, define the specific ‘stack_name_ + service_name’ in the following command:
docker service logs stack_name_service_name
Want to scale? Create more instances of a service and scale them quickly across qualified nodes:
docker service scale stack_name_service_name=replicas
docker service scale caylent_api=5
As with any project, it’s important to keep your workspace tidy. To rid yourself of unused containers and images that take up precious disk space, here are a few clean-up commands.
To clean—or prune—unused (dangling) images:
(Note: These commands will prompt a ‘WARNING!’ alert asking if you’re sure you want to continue, simply enter y to move forward.)
docker image prune
To remove all images which are not in use by existing containers, add the -a flag:
docker image prune -a
Unless you started a container with –rm, it will not be automatically removed. Use ‘docker ps -a to view everything, then delete all stopped containers with:
docker container prune
To prune your entire system—including images, containers, and networks—use:
(Note: With version Docker 17.06.1 and higher, you must include the –volumes flag too for this command to prune volumes.)
docker system prune
You’ll receive this alert to be sure you wish to continue:
WARNING! This will remove:
– all stopped containers
– all networks not used by at least one container
– all dangling images
– all build cache
Are you sure you want to continue? [y/N] y
To leave a swarm:
docker swarm leave
To remove a swarm:
(Be warned! This will delete all volume data and database information also!)
docker stack rm stack_name
To kill all running containers: (As mentioned, this is an all or nothing command.)
docker kill $(docker ps -q)
Here are a few other useful commands to help you get started, ones we think are worth keeping at hand.
To view all running containers:
And for more information on any Docker command, run:
docker swarm command –help
Find the most important of these commands and a Docker Commands basic structure reminder on our attached Docker Commands Cheat Sheet. An all in one PDF to keep at hand.
Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with microservices, containers, cloud infrastructure, and CI/CD deployments. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and profit from our DevOps-as-a-Service offering too.