Gain insights into Docker, its impact on development, and why it's essential. Learn about creating, deploying, and running applications with containers to enhance your software and career.

datad.tar.gz

docker-hello

docker-file

docker-file-ex

docker-env1

docker-env2

docker_env1_ex

docker_env2_ex

docker_size

dot-net

node

python

nginx

jenkins

nextCloud

By now, you've probably heard the buzz around Docker. It's fundamentally changed the development process and been adopted by software teams of all sizes, and for good reason: Docker makes it considerably easier to create, deploy, and run applications with the use of containers.

Docker is here to stay, and is becoming one of the most in-demand technologies on the market. Mastering it now will help you produce better software, level up your career, and stand out from the crowd. Get started today.

Docker for Developers

Earlier, we saw that image names include a name and a tag. As a quick reminder, an image name is:

~~~~~~~~
<repository_name>/<name>:<tag>
~~~~~~~~

* *tag* is optional; when missing, it is considered to be *latest* by default
* *repository_name* can be a registry DNS or the name of a registry in the Docker Hub

While your images aren't published to a registry, you don't need to include a registry name. So, your image name is:

~~~~~~~~
<name>:<tag>
~~~~~~~~

# The *latest* tag

In my demonstrations I didn't include a tag; therefore the default *latest* tag was used. For instance, the actual image name was *hello:latest* when I ran the following command:



As long as you are creating simple software, running on a simple CI/CD pipeline, it can be fine to use the *latest* tag. In a simple scenario, you may:

1. Update the source code
2. Build a new image with the *latest* tag
3. Run a new container with the newest image
4. Kill the previous container

There's a caveat with this however: when using the *docker run hello* command on a distant machine (which actually means docker run <i>hello:<b>latest</b></i>), the distant machine has no means to know that there is a newer version of the *hello:latest* image. You need to run the *docker pull hello* command on the distant machine in order for the newest version of your image to be downloaded to that machine.

This may sound awkward, and that's one reason for not just using the *latest* tag. 

# Why Would You Tag Your Images?

Other reasons come to mind once you become more serious with your CI/CD pipeline. For instance, you may want any or all of the following features:

* Be able to roll back to a previous version of an image if you detect a problem with the latest image.

* Run different versions in different environments. For instance, the latest version in a test environment and the previous version in a production environment.

* Run different versions at the same time, routing some users to the latest version and some to the previous versions. This is known as a canary release.

* Deploy different versions to different users, and be able to run whatever version on your development machine while you support them.

These are all good reasons for tagging your images. If you ensure each released image has a different tag, you can run any of the scenarios mentioned above.

You're free to tag your images however you want. Common tags include:

* a version number, e.g. *hello:1.0*, *hello:1.1*, *hello:1.2*

* a Git commit tag, e.g. *hello:2cd7e376*, *hello:b43a14bb*

In order to apply a tag, just state it during your build command:



In a previous lesson, we mentioned that an image name can include an optional tag. In this lesson, we will discuss tags in a bit more detail and learn why they are important.

Before Getting Started

Why Docker?

Get Docker up and Running

Basic Concepts

Use Docker Images

Create Docker Images

Publish Docker Images

Forget SDK Installs

Docker with Common Development Profiles

More About Running Containers

Tags Matter