DEV Community: Alex Ortiz

docker learn #07: A Tiny Post about Image Size & Run Times

Alex Ortiz — Sat, 23 Nov 2019 04:24:35 +0000

I have the tiniest of Docker Learn write-ups this week. 🙃

Alpine Builds and Runs so QUICKLY

Suppose you try each of the following commands:

docker run ubuntu
docker run fedora
docker run alpine
docker run golang

The first two commands install images and run super short-lived containers based on Ubuntu Linux and Fedora Linux, respectively. The third one does the same, but on Alpine Linux. By now I know that Alpine is 10x smaller than Ubuntu, but running these commands really brought the point home about why that makes a difference.

With the first two commands, it took a few seconds for the Docker daemon to download the images before it could run the container. But the third image (Alpine) downloaded so quickly that I almost didn't even notice the progress bar for it in the Docker terminal. The fourth command, on the other hand, took longer to execute than the first three combined.

`docker images` = `docker image ls`

If I run docker images or docker image ls, both commands will output the same thing:

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
golang              latest              54e71dcafb7c        3 weeks ago         803MB
ubuntu              latest              775349758637        3 weeks ago         64.2MB
fedora              latest              f0858ad3febd        3 weeks ago         194MB
alpine              latest              965ea09ff2eb        4 weeks ago         5.55MB

This is a useful command, as I can now quickly compare the four images from above, by image size. The output seems to be sorted by image creation date rather than size. But it's still easy to compare the image sizes—and it's now obvious why the alpine image downloaded so quickly and the golang image so slowly, relatively speaking. Alpine was just 5.55 MB in size, compared to Golang's 803 MB.

By the way, docker images ls -a will also output the same information. (I don't yet know under what conditions this would not be the case)

And that's it! Until next week 👋🏾.

docker learn #06: Hello Python in Alpine

Alex Ortiz — Sat, 16 Nov 2019 05:15:25 +0000

So here I am with a full month of Docker under my belt, wondering what I can do to show myself my progress. To decide what to write about this week, let me start from scratch: what do I know?

I know that to run a docker container, I need a docker image. And to build a docker image, I need a Dockerfile, which contains the files plus metadata necessary to run a self-contained environment. The environment includes an operating system and the application I wish to run. For example, if I want to run a Python3 shell inside a container as if I were running it on my local machine's terminal, then I'm going to need, at a minimum, the following environment:

an operating system on which to run Python3
the Python3 programming language installed on the OS
a command line interface to interact with Python3 in shell mode

In other words, I need to be able to run the Python3 shell inside a terminal inside a Linux Docker container.

Easy enough.

Installing a Base Image...but Which One?

First up is the operating system.

Python is a pretty lightweight language that just about any operating system can handle. So I want to use a super lightweight Linux distribution to serve as my operating system for this exercise. In lieu of Ubuntu, let's go with Alpine, which is 1/10th the size.

If I run the following command from my Docker CLI, though, I'll run into trouble right away:

docker run alpine

I won't want to run just this command, because if I do, then this happens:

my Docker client calls the docker daemon via the Docker API
it tells the daemon that I want to run an alpine container (totally is true)
the daemon will dutifully do all this stuff:
- pull the alpine image from Docker Hub 💪🏾
- run the alpine image on my Docker server 💪🏾
- run an alpine container from this image 💪🏾
- immediately exit said container 😤

This is because the Dockerfile for an alpine image has but one command that runs as default: "/bin/sh".

So when I tell Docker to pull or run alpine, it does that, and the base image runs, and it does what it's supposed to, but then the shell a) doesn't receive any additional instructions, b) determines that there is nothing for it to do, and consequently c) stops running, which leaves the container without a process to run, causing the container to be terminated (exited). No process, no container. I get it.

Side Note 1: This can be confirmed with the docker ps -a command, which will show that an alpine container did indeed momentarily run but was then exited.

This is of course no good to me if what I want to do is run Python3 inside a container.

So it's time to break out the useful -ti flag.

Using `-ti` To Run an Interactive Terminal

For all the above reasons, I run the following instead:

docker run -ti alpine

There we go. Now the docker daemon will do its thing again, but this time, the alpine container won't exit. The combo of the two Docker flags t and i will instruct Docker to please allocate me a terminal and patiently listen for my input.

I'll now be able to use the built-in shell to move on to my next step: installing Python3 inside this container.

Adding Python3 with the Alpine Package Manager, apk

Alpine Linux doesn't come with Python3 pre-installed. You have to install it manually. It's very simple to do with the alpine package manager, apk. A quick check of the Alpine Linux APK website shows that python3 is indeed one of the packages.

Since I'm now running an Alpine Linux docker container with an interactive terminal waiting for me to provide further instruction, I can proceed:

apk add python3

This will install python3 on my alpine operating system inside the Docker container. I can confirm the installation afterwards by typing python3 --version into the alpine terminal, which outputs Python 3.7.5:

/ # python3 --version
Python 3.7.5

We're in business! On to the final step: launching Python3 in shell mode.

Side Note 2: By the way, the presence of / # indicates that I'm in the interactive shell terminal within my alpine container.

Actually Running Python3 in Shell Mode

At last, I can run Python3. Since I just installed python3, I can simply run it by typing python3:

/ # python3
Python 3.7.5 (default, Oct 17 2019, 12:25:15) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

The presence of >>> indicates that I'm in Python3's shell mode. That is, I am now actually running the Python3 application. Now for the fun stuff! 😎

Taking on a Small Python Challenge

Now that I have Python running in shell mode inside an interactive shell terminal inside an Alpine Docker container, I can take on a fun challenge. For example, my Educative team recently wrote a blog post with six fun Python challenges.

Let's try two of them right now :).

Challenge #1: World, Can You Hear Me?

Here was my team's prompt to readers:

Challenge accepted. In my Docker container, I type this:

>>> print("Hello World\nLet's Learn Python\nSincerely, Alex")

And the Python shell prints the following:

Hello World
Let's Learn Python
Sincerely, Alex

Challenge #2: Some Maths and Physics

Here was my team's prompt to readers:

They also provided the following values:

G = 6.67 x 10^^-11
MSun = 2.0 x 10³⁰
mEarth = 6.0 x 10²⁴
r = 1.5 x 10¹¹

So in my Docker container, I created variables G, M, m, and r and stored their respective values in each, using Python-friendly scientific notation. Then I created the variable grav_force as instructed, though converting it into the Python-friendly notation. Finally, I instructed Python to print the variable I just created, outputting the result of Newton's beautiful gravitational force equation.

Putting this all together, it was like so:

>>> G = 6.67e-11
>>> M = 2.0e30
>>> m = 6.0e24
>>> r = 1.5e11
>>> grav_force = (G*M*m)/(r*r)
>>> print(grav_force)
3.5573333333333336e+22

Close enough, and not bad for this all running inside a Docker container! :)

I then type (exit) to exit the Python3 shell, and then exit to exit the alpine container I've been using. To confirm that the daemon terminated the container, I use docker ps -a -l, and it shows me that the last container that ran indeed was exited, seconds ago.

Wrapping Up

I've once again run out of time to write all the other cool stuff I learned this week or am excited about with respect to Docker. But I'm really happy that I got to "test" myself by starting from what I've learned so far and then moving towards a tangible demonstration of my learnings—even crossing over into Python-land.

And did I mention how sweet it is that we just saw how easy and cool it is to run Python-in-Linux-in-Docker?

Very cool indeed. Till next time!

// Detect dark theme var iframe = document.getElementById('tweet-1195572759645917184-502'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1195572759645917184&theme=dark" }

You know the drill: hit the DEV.to Follow button, follow me on Twitter @alexoeducative, and definitely visit our blog. Chat or comment below if you'd like to add any Alpine or Docker knowledge!

docker learn #05: An Interesting --Help Quest

Alex Ortiz — Sat, 09 Nov 2019 00:39:21 +0000

This week, I wanted to poke around the Docker command line interface (CLI) to see how it can help me troubleshoot something or accomplish a goal. A few weeks ago as I was reading the very awesome book Docker Up & Running: Shipping Reliable Containers in Production by Sean P. Kane and Karl Matthias, I scribbled down a note next to a command. The scribble was, "What does --rm do?".

What does `--rm` do?

If you've already created a docker container and you want to manually remove it from your host, you can use the command docker rm <containername>.

But if what you want to do is use a single command to instruct the docker daemon to do three things—

1) pull an image,
2) create and run a container from that image, AND
3) remove the container right after

—then you can use docker run --rm.

Last week, I ran docker run ubuntu, which pulled the ubuntu:latest image, ran an instance (container) of that image with the command /bin/bash, and exited the container afterwards. Recall that this happens because Ubuntu is not an application or process but rather a base operating system image, so by design the ensuing container doesn't have any process running inside and is therefore terminated fractions of a second after it runs. But we were still able to double-check that the container indeed ran by typing docker ps -a.

However, let's see what happens if we use an alternative command with the --rm option:

docker run --rm ubuntu

What does this do? Let's find out by using Docker's insanely helpful --help option in the CLI.

When to gladly ask for `--help`

If we type docker run --help, the inline Docker manual tells us that the --rm flag will "automatically remove the container when it exits".

We can check for this because neither docker ps nor docker ps -a will list any container. But this begs the question: how can we tell the difference between "never having run any containers" and "having run containers that have since been deleted (or automatically removed)"?

Let's see if docker --help can give us such clues.

First, try running docker --help in your CLI. That will print the following:

$ docker --help

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Options:
      --config string      Location of client config files (default "/root/.docker")
  -c, --context string     Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and
                           default context set with "docker context use")
  -D, --debug              Enable debug mode
  -H, --host list          Daemon socket(s) to connect to
  -l, --log-level string   Set the logging level ("debug"|"info"|"warn"|"error"|"fatal") (default "info")
      --tls                Use TLS; implied by --tlsverify
      --tlscacert string   Trust certs signed only by this CA (default "/root/.docker/ca.pem")
      --tlscert string     Path to TLS certificate file (default "/root/.docker/cert.pem")
      --tlskey string      Path to TLS key file (default "/root/.docker/key.pem")
      --tlsverify          Use TLS and verify the remote
  -v, --version            Print version information and quit

Management Commands:
  app*        Docker Application (Docker Inc., v0.8.0)
  builder     Manage builds
  checkpoint  Manage checkpoints
  config      Manage Docker configs
  container   Manage containers
  context     Manage contexts
  engine      Manage the docker engine
  image       Manage images
  manifest    Manage Docker image manifests and manifest lists
  network     Manage networks
  node        Manage Swarm nodes
  plugin      Manage plugins
  secret      Manage Docker secrets
  service     Manage services
  stack       Manage Docker stacks
  swarm       Manage Swarm
  system      Manage Docker
  trust       Manage trust on Docker images
  volume      Manage volumes

Commands:
  attach      Attach local standard input, output, and error streams to a running container
  build       Build an image from a Dockerfile
  commit      Create a new image from a container's changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  deploy      Deploy a new stack or update an existing stack
  diff        Inspect changes to files or directories on a container's filesystem
  events      Get real time events from the server
  exec        Run a command in a running container
  export      Export a container's filesystem as a tar archive
  history     Show the history of an image
  images      List images
  import      Import the contents from a tarball to create a filesystem image
  info        Display system-wide information
  inspect     Return low-level information on Docker objects
  kill        Kill one or more running containers
  load        Load an image from a tar archive or STDIN
  login       Log in to a Docker registry
  logout      Log out from a Docker registry
  logs        Fetch the logs of a container
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  ps          List containers
  pull        Pull an image or a repository from a registry
  push        Push an image or a repository to a registry
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  rmi         Remove one or more images
  run         Run a command in a new container
  save        Save one or more images to a tar archive (streamed to STDOUT by default)
  search      Search the Docker Hub for images
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  tag         Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  version     Show the Docker version information
  wait        Block until one or more containers stop, then print their exit codes

Our goal is to figure out if there's a command in Docker that will show us a historical record of any containers that we previously ran, even if they were eventually deleted. So what we want to do is look for clues in the --help printout as to which command may help us display such a record.

Unfortunately for us, none of the Options in the list seem relevant to this quest. But in the Management Commands section, container looks promising.

So let's run docker container --help to drill down on what the container command does. Here's the output:

$ docker container --help

Usage:  docker container COMMAND

Manage containers

Commands:
  attach      Attach local standard input, output, and error streams to a running container
  commit      Create a new image from a container's changes
  cp          Copy files/folders between a container and the local filesystem
  create      Create a new container
  diff        Inspect changes to files or directories on a container's filesystem
  exec        Run a command in a running container
  export      Export a container's filesystem as a tar archive
  inspect     Display detailed information on one or more containers
  kill        Kill one or more running containers
  logs        Fetch the logs of a container
  ls          List containers
  pause       Pause all processes within one or more containers
  port        List port mappings or a specific mapping for the container
  prune       Remove all stopped containers
  rename      Rename a container
  restart     Restart one or more containers
  rm          Remove one or more containers
  run         Run a command in a new container
  start       Start one or more stopped containers
  stats       Display a live stream of container(s) resource usage statistics
  stop        Stop one or more running containers
  top         Display the running processes of a container
  unpause     Unpause all processes within one or more containers
  update      Update configuration of one or more containers
  wait        Block until one or more containers stop, then print their exit codes

Ah! The container command is used to manage containers, which we can do by using all the commands listed just above. Among them, the inspect and logs commands initially appear to have potential. Sadly, they won't help either: we don't actually know the name or container ID of a container to refer these commands to. Alone, docker container inspect and docker container logs won't actually turn up anything. Neither will docker container ls, since there are no containers running.

In the main list of commands above, I discovered a command I hadn't used before: docker info. In addition to running docker ps -a, we can use docker info to confirm that no containers are running. It will list, among much else, the following:

$ docker info

[...]

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1

[...]

So yea. We have one image (i.e., ubuntu:latest) running, but zero containers. With zero containers running, and no containers that ran but have not yet been deleted, we can't retrieve a container ID, which is necessary to use the inspect or logs command.

We are at a dead end.

Where to, From Here?

What we need is a list of activity that will display the container ID of the container that was created and exited when we first ran docker run --rm ubuntu above. However, none of the commands explored above, or found through the --help option, seem to do that.

At this point, one has to wonder if our assumption is even correct: does Docker even keep a log of containers that ran in the past (or during the current session) but no longer exist? On the one hand, this would be useful, to be able to distinguish "containers that happened" yet are no longer visible from "containers that never happened". If the daemon doesn't know the difference, then neither can we.

Being at this impasse, if I Google, "how to list the last docker container that ran", I only find two things that offer clues as to possible next steps:

Some folks who wished to restore an accidentally deleted container have been able to do so by navigating to the directory /var/lib/docker/volumes/<containerIDfolder>/_data. I don't know how to do that yet, though.
Docker's documentation describes the interplay between the local storage area of a running container and the /data directory on a Docker host

But alas, we are once again out of time for this week's post. This has been a great way to get to know the Docker CLI and how to leverage docker --help to quickly read the manual when attempting to solve a basic problem.

Great learning exercise! :)

This Week's Docker Answer Roundup

I'm back on my Q&A grind. Here are a few questions I answered this week.

On deploying AI models using containers

Q: How can I deploy AI models using Kubernetes?

Here's my answer:

For this question, you might find inspiration in some of the work being done to run ML models as microservices using a combination of Python, Flask, Docker, IBM’s Data Asset Exchange (DAX) network for open source data sets, IBM’s Model Asset Exchange (MAX) for open source deep learning models, and cloud-based Functions-as-a-Service (FaaS) platforms such as IBM’s own OpenWhisk.

What Docker does in this context is provide the containers and container runtime engine within which to perform certain aspects of training and using your models. If you have a need to run multiple, interacting containers, you might then use a container orchestrator such as Kubernetes. But the details will vary by your use case.

(The reason I say inspiration above is that there may be other approaches to doing something similar for what you want. Whereas the IBM approach is obviously targeted at enterprise uses of AI models, perhaps what you have in mind isn’t aimed at enterprise use cases. Nonetheless, the approach may offer you clues as to how you can go about doing what you’d like to do with containers).

Check out the following resources to see if there’s something helpful there:

And here’s the recording of the presentation in the last link above (the lecture slides are in the comments of the video - see “Session Materials”):

On using multiple containers for a web app

Q: Would you put the frontend and the backend of a web app in different docker containers?

Here's my answer:

Ideally and in many scenarios, yes. One of the software design practices that Docker is suited to (and subtly enforces) is the isolation of processes in an application stack. This helps with long-term scalability, especially if you anticipate your app being used in a way that requires running thousands of containers or more. Since a Docker container is a single, short-lived instance of a single task, process, or application, then it might make more sense to separate the front-end component from the back-end one(s). For example:

NodeJS in one container, with a MySQL database in another
PHP running in one container, nginx running in a second container, and MariaDB running in a third
A container with your front-end, another container with a cache service like Redis, and a database like MongoDB or CouchDB in yet another

In all of these scenarios involving multiple containers that are all necessary for your app to work, you’ll likely need a container orchestrator such as Docker Compose, Mesos, or Kubernetes.
Hope that helps.

On the future of container virtualization

Q: Do you see Windows containers as the next step in the evolution in virtualization or is it something that may fade away?

Here's my answer:

I’ll answer this more generally. With technology, it’s so hard to make predictions. Sure bets don’t always work out, and relative unknowns can become dominant forces over time. Within the span of 24–36 months, certain technologies and products can go from low adoption rates to rapid growth and eventually scale. So looking at the current state doesn’t help us much in anticipating the future; nobody can say for certain if Windows containers or Windows container runtime engines will or won’t experience rapid adoption in the future or become the go-to technology for OS-level virtualization. Just because something like 99% of the container ecosystem today is Linux-based doesn’t mean that this can’t change.

However, from what I’ve learned about containers and the container ecosystem—and I’m still at the very early stages of my learning—a few things are worth noting:

Technologies that experience rapid adoption usually benefit from a lot of work that came before it. This is true in every tech space, but here are two examples involving containers.
- Docker has been a very successful container runtime engine, but its success came after lot of work by a lot of companies had been done on Linux kernels and containers. Perhaps there is foundational work being done today on Windows containers and Windows container runtime engines that isn’t visible to the mainstream but that will someday be looked upon as an example of why Windows containers became wildly successful.
- Kubernetes has gained immense popularity as a Linux container orchestrator, but Google was working on Kubernetes for many years and was running millions of containers with it before it open-sourced the project. Years later (today), Kubernetes seems like the container orchestrator. But perhaps Titus (Netflix’s orchestrator) will be the go-to orchestrator for tomorrow. Who’s to say that an orchestrator natively based on Windows containers won’t become the Kubernetes or Titus of tomorrow?
Communities and network effects are wonderful, interesting drivers of product adoption. For instance, Facebook launched in 2004. It’s just fifteen years old. In a mere five 36-month timespans, it’s become the #6 most valuable company in the world and one of the most valuable companies of all time. It became that valuable this quickly due to its rapid adoption, the nature of networks and communities, and other just-in-time factors such as a rise in mobile phones, the reduced cost of telecommunications infrastructure, and new trends in how we consume media
- By analogy, Docker and Kubernetes have enjoyed relatively rapid adoption cycles within their user communities. This is in part because Docker and Kubernetes solved a problem for a large addressable market of developers, engineers, and businesses. It’s likely also the case that these two technologies have benefited from good timing, emerging at a time when variables external to them have nevertheless positively impacted their adoption curves. If Windows container and container runtime tools emerge under analogous circumstances, then who knows what will happen

In summary, it isn’t inconceivable to imagine that in the next 5–10 years, a useful Windows container technology could emerge just as the market is ready for it. I’m not saying that it will happen, but I’m saying that it’s unrealistic to think that it can’t. Businesses tend to respond to the behaviors and expectations of their consumers. Technologies tend towards addressing the needs and requirements that arise because of this. So the evolution of containers—be that with respect to Linux, Windows, or anything else—will likely be influenced by the interplay between these two factors.

On image registries

Q: Where does Kubernetes pull images from?

Here's my answer:

Since Kubernetes is a container orchestrator and containers are built from container images (such as a Docker image), the images pulled by Kubernetes are also stored in a public or private container image registry. The technical documentation for Kubernetes says that you “can create your Docker image and push it to a registry before referring to it in a Kubernetes pod”.

Examples of image registries include Docker Hub, Docker Registry, Docker Trusted Registry (DTR) for enterprise, Google Container Registry, Amazon Elastic Container Registry (Amazon ECR), and many others. These all work with Kubernetes, so you can refer your images to your Kubernetes pods accordingly, pulling from a private registry if necessary.

On `docker push`

Q: How do I push an image to Docker Hub?

Here's my answer:

This is typically accomplished from the Docker client with the following command: docker push. What this command does, per Docker’s technical documentation, is to “push an image or a repository to a registry”. You can push an image to a public image repository such as Docker Hub, or to a private registry (see here for another answer of mine which references several public and private image repos).

On whether or not programmers should learn about orchestrators

Q: If you work in programming, should you learn Kubernetes?

Here's my answer:

This really depends on what you’d like to accomplish and if your programming work will require deploying containerized applications. If that’s the case, then learning about Docker may be a good investment of time, as that’s by far the most popular container runtime engine today. Docker is also heavily architected into Kubernetes. However, working with Kubernetes is a highly specialized skill and will likely take time to learn. If you do go in that direction, consider this resource.

I do hear that being able to debug and test your code in production with containers is a valuable skill to master, so if you plan to use Linux containers as part of your application stacks, then investing in learning Docker is likely a great idea.

Helpful Resources

These may be of service to you:

I must say, one of the best Docker presentations I've seen thus far is Jerome Petazzoni's 2015 talk, Cgroups, namespaces, and beyond: what are containers made from?
I've also started watching a much longer talk of Jerome's, his three-hour Introduction to Docker and Containers from PyCon 2016. It's accompanied by an INSANE resource at https://container.training/, with videos, previous workshops and presentations, and lecture slides for self-paced review. Enjoy!

And that about does it for this week's docker learn. Thanks for spending some of your time with me, my learning, and my series! Have an awesome weekend, everyone!

docker shoutout

My Educative team runs a pretty awesome blog. Not only do we interview amazing Educative Authors like C# legend Eric Lippert, but also sometimes we have guest blog posts on topics that—you guessed it—relate to container technologies. Two of our guest articles have been by Microsoft Developer Advocate and Docker Captain Scott Coulton. The two pieces are about Kubernetes, and since this week I answered a few K8s-related Docker questions, go ahead and also read Scott's Educative posts if you so fancy 😎👉🏾:

Hit the heart button, share this DEV article with someone you care about, and see ya soon! <3

docker learn #04: Hanging Out with Ubuntu

Alex Ortiz — Sat, 02 Nov 2019 04:38:24 +0000

Sometimes, the best way to practice is to, well, practice. For this week's learning snapshot, I'm going to share what it's like to use a few basic commands in Docker. Let's use Ubuntu, one of the most popular Linux distributions out there, to very temporarily run a container. And let's see how to check that we've done so.

Hanging Out with Ubuntu

Ubuntu is an operating system in the Debian family, as opposed to, for instance, Fedora. For practice, let's use Docker to run a Linux container on the Ubuntu operating system.

Say you run this command in Docker for the first time from your Docker client:

docker run ubuntu

Your client will pass the run instruction to the docker daemon (the server that hosts the Docker Engine, which is the runtime on which containers run).

First, the daemon will try to find the ubuntu image locally: it will check to see if the image is already on the server itself. If the daemon doesn't find the image—and it won't in this case, because this is the first time you've tried to run an ubuntu container—then it will display a series of messages on your Docker command line interface (CLI) as it does each of the following:

display a message confirming it did not find the image locally
pull the image from the Docker registry where the image is stored, defaulting to the image with the latest tag
show statuses, one per line, as it downloads each of the image layers associated with the ubuntu image—in this case, the ubuntu:latest image had four layers. As each layer succeeded, the CLI displayed a message that contained a short version of the SHA256 hash for that layer, along with the words "Pull complete"
display the full SHA256 digest for the ubuntu image in question
show a confirmation message, Status: Downloaded newer image for ubuntu:latest

So for example:

From Docker Playground

Great! So now we have our Ubuntu image on our Docker host, and we've actually run a Linux container based on Ubuntu. You can verify this by typing docker ps.

Uh-oh: Where's that Container?

But wait! You won't see anything listed. As I mentioned in my last post, certain containers, such as containers based on base operating system images, are exited almost immediately after they run. This is because if a container doesn't have a running process (the whole point of a container), it will be exited. And in the case of an Ubuntu container that's not doing anything special, its Bash shell will run for a split second, then not see any script to run in that shell, and therefore exit. Then the container will have nothing to do, so the daemon will stop the container.

(Sidebar: If you're wondering what I'm on about, remember that every docker image is created from a Dockerfile, which has one or more lines of instructions in it. Each line in a Dockerfile is used to create one layer, and all those layers collectively make up the actual docker image. From those four status messages I mentioned up above, we can deduce that the Dockerfile used to create the particular Ubuntu image we are now using had four lines, and thus four layers, in total—one of which is for the command /bin/bash. See below.)

Ah, There it Is

You can confirm that all this happened by running the command docker ps -a, whereupon your CLI will show you the following information:

a Container ID
the docker image the container was based on
a command if one was executed in the container ("/bin/bash", in this case)
when said container was created
the Status of the container, along with an exit code (like "0", which means "no errors"
a randomly generated but usually whimsical Name for the container (e.g., "youthful_galileo")
some other etceteras

So for example:

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                      PORTS               NAMES
blahblahblah        ubuntu              "/bin/bash"         21 minutes ago      Exited (0) 21 minutes ago                       youthful_galileo

And there you have it. We've met our goals of running an Ubuntu Linux container using Docker and checking that we indeed ran it.

From here, there's tons more that we could do:

Use docker start <containername> to restart the exited container
Use docker inspect <containername> to get loads of detailed information about the container
Use docker rm <containername> to remove the container from the host
Use docker rmi ubuntu to remove the Ubuntu image itself from the host, in preparation for other cool commands

We might use docker pull ubuntu to pull the Ubuntu image to our daemon, but not create a container from it just yet. Or we could use docker create ubuntu to both pull the Ubuntu image and create a container but not yet run it. Or we could go all in with docker create --name="cool_fridaynight" ubuntu to do everything we just did plus give the container a cool custom name. 😎

But alas, we're out of time this week. Till next time!

docker shoutout

There's a joy to learning new things, and I hope you're enjoying these writings. So if you like my series, hit the follow button and share the link with one other person. Show some <3 or a 🦄. And follow my Educative team here on Dev.to. Speaking of which, I'd like to plug a very special announcement:

Alex Ortiz

@alexoeducative

This is supremely cool 😎! We've partnered with @GitHub's @GitHubEducation to offer 1M+ students free access to six months of @EducativeInc courses! The GitHub Student Developer Pack now includes 60+ of our amazing software development courses educative.io/github-students 💪🏾🎉💻🎓

21:35 PM - 31 Oct 2019

10 31

💪🏾🎓

See you next week! Happy learning.

docker learn #03: Learnings from Silicon Valley

Alex Ortiz — Sat, 26 Oct 2019 00:13:07 +0000

I went to Silicon Valley last weekend for the Silicon Valley Code Camp SVCC 2019, held at PayPal's global headquarters. Here's me looking mesmerized at one of the many very awesome talks:

From "Silicon Valley Code Camp Saturday" by Peter Kellner

As you can imagine, at a conference full of topics related to software development, engineering, operations, security, and cloud architecture, Docker came up quite a bit, so I learned a lot because of it 🎉. Here's some of what I learned on this awesome work trip.

Everything I Learned about Docker in Silicon Valley Last Weekend

First, here were the sessions I attended. Where Docker came up, I've tagged it with docker:

Knowing Linux and Docker Security for Kubernetes Security by Sunil Sabat docker
Deploy deep learning models as a web microservice in minutes by Shruthi Swaminathan docker
Getting Started with The Go Programming Language ( golang ) by Todd McLeod docker
Introduction to Kubernetes and OpenShift by Dave Nugent docker
ACID Transactions with MongoDB by Nuri Halperin
Powering DesignOps at PayPal by Stan Carrico
How Humans Learn and Why It Matters by Ted Young
Serverless Swift - for Effective Backend as a Service by Marek Sadowski docker
Serverless containers - a match made in heaven by Martin Omander docker
Building Reliable and Resilient Services by Manoj Agarwal
Master Dynamic Programming by Hien Luu

And now for some insights! The stuff below isn't sorted by importance or by the lecture I learned or heard it in.

Container Adoption Skyrocketed in the Last Three Years; May Double in the Next Three

The 2019 Container Adoption Survey predicts that container technology will be a $4.3B market by 2022, double what it is today ($2.1B). To put that further into context, Dave Nugent explained that 87% of IT Admins who responded to that survey this year are running containers, and 90% of those containers are in production. Of the IT Admins who responded, 65% are using two or more orchestration tools, such as Kubernetes. (Just three years ago, 72% of respondents had said that no, they were not using orchestration services. By last year, the numbers had climbed only a little, with only 34% of respondents saying they were using Kubernetes. So those figures from 2019 are impressive).

On that note, if you know containers, you know how popular Google's container orchestration technology Kubernetes is. On the Kubernetes repo on GitHub, you can see that it has 84,000+ commits, 2,200+ open issues, and a whopping 30,000 issues that are closed.

In other words, containers and their orchestrators are on very heavy rotation.

A Little Go History, and its Choice for both Docker and Kubernetes

From Todd McLeod's presentation, I learned how Golang was invented. In 2005, Google assessed every programming language on the planet but didn't find any that met their needs at the time. For context, multicore computers were a new thing, so there weren't yet any programming languages capable of natively benefitting from such computers, i.e., using multiple cores to benefit from parallelism.

Google wanted three things:

1) ease of programming
2) efficient execution
3) efficient compilation

After not finding a language that could achieve all three, and wishing to utilize a language that could take advantage of multicore processing, Google asked Ken Thompson (of B, C, Unix, and UTF-8), Robert G (of HotSpot and JVM), and Rob Pike (also of Unix, UTF-8) to create such a language, and Go was the result.

Kubernetes and Go both coming from Google, I get why Go was the obvious choice to write Kubernetes. What's interesting is that Docker is also written in Go. Perhaps Go was chosen for Docker because of Go's reputation as a security-conscious, type-safe, and fast language, or it could have been a coincidence.

Alternatives to Docker?

I noticed that Docker had the strongest word-of-mouth of any container platform throughout the conference. There are other container runtime engines, such as containerd and CoreOS's rkt. But Docker is by far the most popular container runtime today.

Even in the enterprise space, Docker is the main contender currently. Both Google via Kubernetes and IBM via Red Hat OpenShift make heavy use of Docker's container infrastructure. But it will be interesting to see if any viable alternatives to Docker emerge in the coming years, in the enterprise or beyond. One space to watch may be Google's relatively new offering, KNative ("Kubernetes meets Serverless"), which is pitched as having the best of containers plus the best of FaaS and PaaS serverless architecture. I don't yet know enough about the history of Linux containers, about why Docker became so popular, and about what Docker did better than anyone else at a technical level and a community level to become so attractive and widely adopted, but in tech, nothing lasts forever. Even top-tier, hyper-popular incumbent technologies get disrupted eventually, and sometimes quickly.

What would it take? This Elon Musk quote is pretty relevant on this point:

"If you're entering anything where there's an existing marketplace, against large, entrenched competitors, then your product or service needs to be much better than theirs. It can't be a little bit better, because then you put yourself in the shoes of the consumer... you're always going to buy the trusted brand unless there's a big difference."

I'm loving learning docker but am also intrigued about larger questions of what makes containers so interesting, and so interesting right now, and what new technologies, new pressures, and new solution trends could mean for containers in the future. Lots to learn!

To Understand Docker Security, Understand Linux Security

As I heard in Sunil Sabat's lecture, the security principles behind Docker (and Kubernetes) actually build on the sound security foundations known to those familiar with the Linux ecosystem. The best practices applied to Linux kernels transfer nicely to Linux containers and Kubernetes clusters & pods.

The building blocks are things like

resource limits on CPU and memory usage and requests
kernel namespaces
control groups (cgroups) for runtime security and to enforce isolation
mandatory access control (MAC)
security profiles, policies, and features like AppArmor, SELinux, and seccomp

All pretty advanced stuff, but also all relevant for the "container supply chain" that extends fro Linux to Docker to Kubernetes and into cloud platforms like AWS or GCP.

Some More TidBits

There's lots more that I learned about at the conference, but here is a roundup of other miscellany:

Cool new concept / term overheard: pre-warmed containers. This is relevant in situations when you want to avoid long "cold-start times" for container images that haven't been run for weeks
With Google Cloud Run, which is a managed platform for stateless containers, it's possible to get Google to run containers for you, and you can later choose to do your own container engineering ops
I heard a cool example of using a container to run an open-source PDF conversion app to automatically convert Word documents into PDFs on GCP
Martin Omander of Google says he recently got a COBOL hello world app running in a container :)
With FaaS/PaaS platforms like IBM OpenWhisk, you can "run anything in Docker as function"
More from IBM: I saw a presentation on how its Model Asset Exchange (MAX) and Data Asset Exchange (DAX) can be used to a) find open-source deep learning algorithms, b) find open-source data sets, and then c) use Docker containers to deploy lightweight neural networks for data analysis. In other words, you can run machine learning models as microservices using Docker. Wow!

There was more, but that's all I can squeeze in for this week. But not before some bonus Q&A!

This Week's Docker Answer Roundup

As I learn, I'm answering questions. Here are a few I answered this week.

On the purpose of Docker

Q: What is the purpose of Docker?

Here's my answer:

The purpose of Docker is to help you create and deploy Linux containers easily, portably, and reliably. For some technology architectures and use cases, running apps on a local machine or a virtual machine makes a lot of sense, but for situations when you want to run stateless applications or tasks that can be containerized quickly and also deployed across dozens, hundreds, or even thousands of users, Linux containers are sometimes the way to go. When that’s the case, Docker gives you a mechanism to create those containers (using Docker images).

On what Dockerfiles are for

Q: What is Dockerfile for in Docker?

Here's my answer:

A Dockerfile is a plaintext document in which you list the instructions Docker needs to use to create a Docker image. From that Docker image, docker containers can later be made and run. (A container is a single process, task, or application.)

The instructions in the Dockerfile include instructions like

which base image (for example, which Linux operating system) your application runs on;
which commands to run or application dependencies to install
files or directories that must be copied to the docker container in order for your app to work correctly
which ports need to be exposed (if applicable) for your application to work
and lots more

All of this information in the Dockerfile is then used by your Docker host (server or daemon) to create a docker image that can be used and reused to build any number of containers.

On the difference between two similar-looking docker commands

Q: What are the differences between the ‘docker run’ and the ‘docker create’?

Here's my answer:

The instruction docker run is really a combo command of two instructions in one: docker create + docker start:

docker create builds you a container from a docker image
docker start instantiates the container

There will be situations in which you want to create a container without actually starting it. If so, you’d use docker create, and later on you’d use docker start.

Here’s an example.

Let’s say you create three linux containers based on the latest version of alpine. Suppose you name them container1, container2, and container3, so that you can refer to them with these custom names rather than with their default names or container IDs.

You would use the following commands:

docker create --name="container1" alpine:latest sleep 600
docker create --name="container2" alpine:latest sleep 600
docker create --name="container3" alpine:latest sleep 600

Here are the components of these instructions:

docker create is the instruction to create the container
--name="custom_name" specifies a key-value pair that names the container
alpine:latest is the docker image from which the container instance is made
sleep 600 is a Linux command (explained below)

Note: Alpine is a lightweight Linux operating system, not an application or process, so if you used docker create --name="container1" alpine:latest, without the sleep command, then Docker would create an alpine container but immediately exit it, because there’s nothing happening inside that container. So for this example’s sake, we keep our three alpine containers running for 10 minutes by using the Linux sleep command set to 600 seconds.

Docker would thus create three alpine containers for you, each remaining active for 600 seconds, i.e., ten minutes. But the three containers would not yet be running.

If you checked this, by typing docker ps -a into the docker command line, your three containers would show up with a STATUS of “Created”.

Now comes the important part. Since you’ve used the docker create command, you could then selectively start one of these containers at will. For example, container1:

docker start container1

Now, container1 would show up with a STATUS of “Up”, and container2 and container3 would continue to show up with a STATUS of “Created”, as before.

From there, you can start, stop, or restart a container as you please. (Of course, in this example, after ten minutes, Docker will exit these containers, per the Sleep instructions from above.)

In summary, docker run creates and immediately starts a container, whereas docker create lets you create a container without starting it. This gives you the flexibility to start and immediately run containers when you need to while also being able to create containers that you don’t. For example, if you wanted to run a command inside a container that had already been created and was already running, it wouldn’t make sense to use the command docker run, as that command always creates a new (additional) container. You would simply use docker create and then docker start instead.

Some Helpful Resources

Here are a few items I found helpful this past week:

Online Playground: Play With Docker
Video: VMWare, Kubernetes in 5 mins
Book: William E Shotts Jr., The Linux Command Line: A Complete Introduction

And with that, I say farewell to another week of docker learn. See you next time!

Hit the follow button, and be sure to stay up to date on all the awesome work my teams are doing at Educative.io and in our EdPresso Community. They are awesome and you should follow them on Twitter at @educativeinc and @edpressoc, respectively.

docker learn #02: Package Managers

Alex Ortiz — Fri, 18 Oct 2019 22:07:42 +0000

Last week, I launched my new docker learn series. I'm learning Docker so I can be more effective in my work at Educative and interacting with the global developer community. I'll be sharing my learning journey as a series of posts, snapshots of what I'm learning as well as how I'm learning it. Hopefully this helps other Docker newbies out there like me, both now and in the future. Here's the second post in the series.

A New Learning: Package Management

In Dockerfiles at work, I'd seen commands like RUN apt-get install xyz and RUN apt-get update and had wondered what they encode. I've since learned that Linux distributions based on Debian use the .deb format for package files, and the Advanced Package Tool, or apt, for package management. So the apt-get install and apt-get update commands are used to prompt a Docker daemon to install or update software packages needed for Docker container payloads to run properly, if those payloads are based on Linux operating systems that are Debian-based, such as Ubuntu.

This is in contrast to Linux distributions based on Red Hat, such as the Fedora operating system, which uses .rpm package formats and package managers like rpm or dnf. Alpine Linux, about which I answer a question below, uses apk for package management. It's cool that, by reading instructions on a Dockerfile, you can make inferences about the underlying operating systems containerized applications utilize.

I feel like I leveled up just writing that.

😜

My Answer Roundup

One of the best ways to learn something is to teach it. By sharing what you know, you achieve two things. First, you get to practice and access your knowledge in a way that maps to a real-world request, which is a subtle form of learning by problem-solving. Second, you pull recently acquired knowledge closer to your center, making it easier for you to assess what you've already internalized and what will extend your knowledge horizon further out.

So I've been answering one question per day on the web. Below is a roundup of those questions. If I got something wrong, go ahead and correct me in the comments (thank you).

On the role of Docker Compose vs that of a Dockerfile

Q: Why do we need Docker Compose when there is Dockerfile (I am a newbie at using Docker)? Am I missing something?

Here's my answer:

Docker lets you run a single instance of one process or task or application inside a container
To run that container, you need a docker image to base the container off of
To create the docker image, you need a Dockerfile—a set of instructions docker will follow to create the necessary docker image
If you’re only running one process/task/app, you only need one container. But what do you do if you have a situation that requires multiple processes/tasks/apps to work together? Well, you might need multiple containers
Docker Compose provides a way to deploy and coordinate—or orchestrate—multiple containers
In that case, you would need a Docker Compose file in the format of JSON or YAML, with information about each process/task/app, how they work together (the relationships between them), their networking and configuration info, and so on
Note that every different process/task/application will need to be built off of a different docker image, and therefore you will need a different Dockerfile for each one. For example, if you’re running an app that requires Node for the frontend and a database for the backend, then you will need a Dockerfile for the image used to create the Node container and a different, separate Dockerfile for the image used to create the database container. Then, you will use a Docker Compose file to coordinate how the two containers will work together
So in summary, a Dockerfile is used to create a docker image capable of running a single instance of one process/task/application inside a container. A Docker Compose file is used to create a pod of containers that work together to bring your multi-container use case to life

On choosing base images for Dockerfiles

Q: When using multiple tools (Node, MySQL, Meteor), what should I choose as a base image for my Dockerfile?

Here's my answer:

This will only partially answer your question, but I hope this is helpful. You won’t just have one Dockerfile: you’ll have more than one. That’s because in the container model, each tool or process—MySQL and Meteor, for example—runs in a separate container. A MySQL container will be based on a MySQL image; a Meteor container will be based on a Meteor image. Therefore, you’ll end up with two separate Dockerfiles, one for MySQL and one for Meteor. (I imagine that because Meteor relies on NodeJS as its language runtime, any Meteor image will already be running node, i.e., the Dockerfile used to build the Meteor image will likely have an instruction to create a NodeJS image layer).

Once you have the Dockerfiles you need to build the images your app requires, then you’ll likely use a container orchestrator like Docker Compose to configure this multi-container setup.

The choice of base image for each Dockerfile is currently beyond my knowledge horizon. But here are a few resources I came across that may or may not be helpful to you:

On what Docker images are

Q: What are Docker Images?

Here's my answer:

The logo of Moby Dock (the blue Docker whale with the 9 shipping containers on top of it) is helpful here. In Docker, each container is, ideally, a single task, process, or application. One per container. The container is a single, short-lived instance of that one task, process, or application. Those containers run on a Linux machine, either natively or on a Linux virtual machine running on Windows or Mac. So in the Docker logo, those nine containers are independent instances of one or more tasks, processes, or applications, and Moby Dock represents the Linux server(s) those containers run on.

To build a container, you need a Docker image. That image is created with a set of instructions, a Dockerfile. Once you build the docker image for a particular task, process, or application, then you and anyone with access to that docker image can easily run as many containers for it.

On why Alpine is popular as a Linux distro

Q: Why is Alpine Linux so popular as base Docker image?

Here's my answer:

The base image for Alpine Linux is much smaller than that of other Linux images, such as Ubuntu. For example, the alpine:latest image is only 2.66 MB in size. By comparison, the ubuntu:latest image is 10X larger: 25.48MB in size. This might not seem like much of a difference, but smaller images and faster build times make a difference when you have apps in production at scale. And for some container applications, Ubuntu might be overkill where Alpine will do just fine. So that’s probably one reason.

But it does come with a trade-off: for example, the Alpine image has the faster and more lightweight Unix shell Ash, whereas the Ubuntu Linux image comes with the more “feature-rich” Unix shells like Bash and Dash.

On Netflix's lack of Kubernetes

Q: Does Netflix use Kubernetes?

Here's my answer:

Netflix does not use Kubernetes. As of 2017, Netflix’s architecture was running millions of Docker containers on virtual machines (VMs) hosted on AWS EC2. But rather than use Kubernetes as the scheduler and orchestrator for all these Docker containers, Netflix built its own container runtime and scheduler, Titus, which was based on Apache Mesos and ran on AWS EC2. You can read more here, here, and here.

On what makes Kubernetes useful

Q: How is Kubernetes so powerful? What can be done with it?

Here's my answer:

Running individual tasks, processes, or software applications in standalone, easy-to-deploy, reliable Linux containers is a great way to add horizontal and vertical scale to a technology stack. But as the number of containers in your architecture grows, so does the need to coordinate them—

how do they talk to each other?
how do you automate the manual-heavy work of building Docker images and deploying containers based on those images?
how do you handle dips and spikes in container use, especially if you have hundreds, or thousands, of containers running at any given time?
how do you deal with containers that rely on other containers before they work, e.g., a database container needs to be active and volume-mounted before another application container can do its job correctly?

All of these things and a dozen other questions are what container schedulers and orchestrators like Kubernetes are meant to help answer. With Kubernetes, you can deploy and manage 1,000 or 2,000 Docker containers while addressing the host of questions I mentioned above. This is a simple starting point but hopefully helpful in contextualizing the power of Kubernetes.

Some Helpful Resources

Here are a few items I found helpful this past week:

Video Presentation: Redbeard, Sysdig and CoreOS Meetup Jul '15: Best Practices For Container Environments
Video Presentation: KodeKloud, Understanding Docker
Article: Eric Chiang, Containers from Scratch

That's all I've got for this week. See you next time!

docker learn #01: My Learning Journey with Docker Begins!

Alex Ortiz — Fri, 11 Oct 2019 22:51:07 +0000

I've started learning Docker.

For context, I'm the Lead of Developer Sales and Success at Educative.io, a software development learning platform for developers and computer science professionals to learn new skills. Our customers love our platform because they can buy high-quality, self-paced courses in the specific programming language, development framework, or topic they need. These courses equip them with new skills, new knowledge, and the confidence to advance in their craft or prepare for new opportunities.

Part of my job is to find software developers and engineers with subject-matter expertise in specific areas. These Authors then create interactive online learning courses to sell on our platform. The courses are text-only (no video) and often contain quizzes, executable code snippets, and interactive challenges that help learners learn. Even though our free tools for writing these courses are pretty sweet, not every language, framework, or library works out-of-the-box. In some cases, the content creator can leverage our Docker functionality to containerize the app or the learning environment their students will need to interact with.

When this happens, I put on my other hat: supporting Authors as they build their courses, acting as a go-between from the external content creator to our internal dev team to answer questions and remove blockers. This can include things like creating custom Dockerfiles, troubleshooting image builds, or customizing docker jobs to work with our teaching tools.

But I don't know Docker. So I've started learning!

In this series, I'll share what I learn as well as the learning journey itself.

On Learning Openly

I'm a big fan of learning openly, of open-sourcing your learning journeys, as they say. It is very satisfying to learn something new and hard and share the learning path with others as you go. You might get some things wrong along the way, of course, but that's part of what learning is: coming to understand a skill or a subject through an ongoing dialogue of hits and misses, successes and failures, roadblocks and open roads.

One upside of this approach is that two things become a resource to others:

your learnings
the learning journey itself

It's the what and the how, packaged together. Whoever follows or joins you along the way can utilize the grooves you've already set.

Note: Take everything I'll share in this series with a learner's grain of salt. Definitely do your own reading (DYOR), and, when in doubt, check out Docker's very excellent documentation.

By the way, this won't be a comprehensive or how-to series per se. It'll be a collection of learning snapshots. So I invite readers of this docker learn series to fill in their own gaps with Youtube videos, books, online courses, Docker's technical documentation, and hands-on exercises. I'll share some of these resources in my posts.

Here we go.

What I've Learned So Far: The Basics and Some Simple Commands

Writing summaries off the top of your head is a great way to review what you're learning. This improves memory consolidation and future recall, and it boosts your confidence.

So here's a simple summary.

Basic Knowledge

Some of the Docker basics I've learned so far include these:

the purpose of a Dockerfile
what a docker container is
how a docker daemon pulls a docker image from the image registry in order to launch a particular container (i.e., an instance of that image)

A Dockerfile is a list of instructions. These instructions are fed from a client to a docker daemon running on a docker host machine (server). The docker daemon consumes the instructions and builds a docker image. The docker image is stored in a registry and downloaded to the host machine the first time you build a container from that image. The docker container includes the specific application, task, or other process you defined in the Dockerfile. When you run a container, you're running a temporary, short-lived instance of that application, task, or process.

A Few Important Basic Commands

Here are some important commands I've learned about:

docker build -> takes a Dockerfile as input and builds a docker image out of it
docker pull xyz -> downloads a specific docker image, which you specify, to your docker host machine, but does not launch a container for that image
docker run xyz -> launches (runs) a container from the image you specify. So, for instance, docker run node will run a NodeJS instance
docker ps -> prints a list of containers you're currently running, along with metadata about each, e.g. name, ID, how long each container has been running, and so on
docker stop xyz -> stops a running container (kinda like force quitting an app, but here it's a containerized instance of that app)
docker start xyz -> starts a container you've previously stopped
docker ps -a -> prints a list of all containers, both the ones running and any you've stopped but haven't yet removed
docker rm xyz -> removes a container you specify (containers run on, and are thus removed from, your docker host)
docker rmi xyz -> deletes an image (as opposed to a container). Note that this removes the image from your docker host machine, but it does not remove it from the docker registry, naturally

There are a lot more commands and many options (flags) for each command, but this is about what I understand at the moment.

Bonus: `MAINTAINER` vs `LABEL`

I learned this week that the docker instruction MAINTAINER has been deprecated in favor of a LABEL instruction. The latter is more flexible and allows the docker image author’s name to be printed alongside other object metadata when running the docker inspect command. So as a best practice, you should use the new approach.

Sample Dockerfile Code - The OLD Way

FROM base_image_name
MAINTAINER image_author_email_address
RUN command_to_run

Sample Dockerfile - The NEW Way

FROM base_image_name
LABEL maintainer="image_author_email_address"
RUN command_to_run

Some Helpful Resources

I'm working through a book and a bunch of videos. Here are just a few:

Book: Docker: Up & Running: Shipping Reliable Containers in Production 2nd Edition by Sean P. Kane and Karl Matthias
Video Presentation: Solomon Hykes, Introduction to Docker
Video Course: Docker for Beginners: Full Course

So there you have it. Independent learning is awesome and really fun. Sharing it is a blast as well.

Thanks for reading docker learn, and see you next time!

docker plugs

For a more extensive treatment of docker from my Educative team and our Authors, check out these other resources:

Our recent blog post, Getting started with Docker and Kubernetes: a beginners guide
Our awesome course, Docker for Developers by Educative Author Arnaud Weil
Our EdPresso shots on writing Dockerfiles and the WORKDIR command, docker build, the CDM instruction, and Docker ADD.

Also hit that DEV.to Follow button, follow me on Twitter @alexoeducative, and check out our courses at Educative.io. If there's a topic you know well or you'd like to build a course, leave a comment—let's chat :).

Conversations with the World's JavaScript Developers Part 1

Alex Ortiz — Sat, 13 Jul 2019 21:21:42 +0000

My work involves speaking with developers throughout the world. We have a platform for developers to share their knowledge with their peers in the format of text-based courses, and my job is to find content creators. So I get to talk to a LOT of developers. For example, in the last four months, I've spoken with 80+ developers and engineers who work in the following areas:

AngularJS, AWS, Bash, CSS, Dart, Data Analytics, Data Visualization, Design Patterns, Docker, EmberJS, Ethereum Blockchain, Firebase, GatsbyJS, Git, Golang, Java Spring, JavaScript, Kotlin, Kubernetes, Machine Learning, Microservices, MongoDB, Next, Node, Objective-C, Perl, Python, R, React, Serverless, Swift, Systems Design, TypeScript, Unit & Automated Testing, VueJS, & Web App Architecture

Recently, I presented to a local JavaScript Meetup group about what I've learned from conversations pertaining to JavaScript, so I decided to share my learnings in the form of this post as well. What's neat about my conversations is that they span both developer tenure and geography: from junior front-end engineers and full-stack developers to 20-year veterans of embedded systems. These professionals come from the following countries: 🇦🇺🇦🇹🇧🇷🇨🇦🇭🇷🇫🇷🇮🇳🇮🇪🇮🇱🇩🇪🇱🇧🇲🇾🇳🇿🇳🇬🇷🇸🇪🇸🇬🇧🇺🇸🇿🇲 (that's Australia, Austria, Brazil, Canada, Croatia, France, India, Ireland, Israel, Germany, Lebanon, Malaysia, New Zealand, Nigeria, Serbia, Spain, the United Kingdom, the United States, and Zambia, with hopefully many more to come). About twenty of these conversations have centered on JavaScript.

Want to learn JavaScript development or land a great JavaScript job? Check out Become a Front-End Developer, React for Front-End Developers, and Ace the JavaScript Coding Interview to see if Educative can help you on your journey.

Here are some of the insights and opinions I've gleaned from JavaScript developers worldwide.

What Keeps Coming Up in Conversation?

The languages that have most come up are plain JavaScript and TypeScript. On the framework side, there's been a much longer list: Angular, Ember, Express, Gatsby, Next, Node, React, React Native, and Vue. Related tools and applications have included Jest to test the Vue framework; Firebase for connecting their JavaScript applications to a cloud-hosted, realtime database; and Redux to manage state.

This brings me to how these developers are using JavaScript in their daily work and in side projects.

How is JavaScript Being Used?

Here are a handful of the use cases I've encountered, all of which will be familiar to JavaScript developers:

building backends with Node, important because JavaScript itself has classically been a front-end language but Node extends upon that
creating web3 blockchain applications with React as the interface between existing web2 architecture and web3 backbones like Ethereum
visualizing large volumes of data using libraries like p5
creating responsive or static websites with Gatsby, GraphQL + Gridsome, or React + Next
with React Native, building mobile business applications that are optimized for high traffic & high API call volumes
functional programming in JavaScript with the Ramda library
building realtime apps and serverless applications

And a lot else.

Why Do JavaScript Developers Love JavaScript? :)

Developers gravitate to different languages for many different reasons. If you're building backends for critical automotive applications, compilers for large social networks, or mobile front-ends for fintech startups, the languages you learn and use will be way different, ranging from C++ and C# to JS. If you're steeped in Kubernetes, you likely know Go. And if your dream is to build next-gen mobile apps, then Kotlin and Swift are on your menu. Besides industry and type of software, other things like personal preference and how good the technical documentation for a language is matter too. This could be its own language-spanning article, but here's what JavaScript developers have mentioned as reasons they love it so much:

JavaScript is easy to grasp, easy to build things with, and pretty
JavaScript has many frameworks, which gives developers flexibility in what they build and how
The JavaScript language and framework ecosystem changes rapidly. For example, React Hooks came out as a feature of React 16.8 just five months ago, yet it already offers some developers an alternative to Redux
As mentioned earlier, JavaScript can be used alongside graphics libraries like p5.js to represent huge amounts of information, which is attractive to data scientists who prefer working with JavaScript over Python
Since the V8 JavaScript Engine used in the world's most popular web browser (Chrome) is "optimized as heck", JavaScript runs very fast on devices used by billions of people. I'm also told that JavaScript handles things like event loop queues well, which creates fewer bottlenecks for web applications and attracts engineers and developers who are conscious of performance

So JavaScript developers love JavaScript for reasons that extend beyond the language itself: it isn't just the ease-of-use, flexibility, and keep-you-on-your-toes freshness it affords its adopters. It's also that because so much of the modern world's technology stack runs—and runs well—on JavaScript, the language is a great choice for building in today's web-connected era. This seems to be the synopsis of sentiment about JavaScript from many.

What JavaScript Developers are Saying about...

Here are a few opinions and observations I've encountered regarding the following:

the TypeScript language
the JavaScript-friendly functional language Elm
the static site and progressive web app framework Gatsby
the UI and single page application framework Vue
the topic of testing

TypeScript

One developer I spoke to mentioned that because JavaScript was originally built so quickly—"it was made in a week"—it has always been a little rough around the edges. So “TypeScript tries to smooth out the rough edges of JavaScript". Additionally, TypeScript has become popular with advocates of type safety, as more developers embrace its importance for their code. And despite TypeScript being fairly new, released a mere six years ago, it's already matured to a point that some developers are using it alongside languages like C# to build complex systems, to assemble offline tools such as command line interfaces, and to create advanced user interfaces and web apps in Angular, per some of the examples I've come across.

Elm

Some JavaScript developers have the opinion that Elm may someday be to TypeScript what TypeScript today is to JavaScript. In this view, a functional programming language like Elm confers a huge working advantage to front-end programmers because it interoperates with JavaScript and can be used to build high-performance graphical user interfaces (GUIs) for web browsers, perhaps for lighter use case scenarios than one would pursue with TypeScript and vanilla JS. So it may be worthwhile to get a head start by learning Elm today if you wish to build the front-ends of tomorrow. On that note, JavaScript developers who want to take on that challenge might enjoy this tip: since Elm inspired Redux, learning Redux first may acclimate the newcomer to Elm faster.

Elm developers for the time being do face a challenge, which is that the Elm community is still very small at a time when communities in other languages and frameworks are experiencing rapid growth.

Vue

Speaking of community, adoption of the Vue framework is growing globally, with large hubs of users in China, Eastern Europe, France, and Nigeria, among other places. One reason Vue is growing so quickly is how easy it is to learn compared to other frameworks for single page websites and user interfaces. The Vue community also exudes an inclusive, welcoming vibe that socially surrounds and engages its members both online and offline. This makes a lot of sense and is true of any space: when it's easier to come by answers and developers are willing to help you, it becomes easier to start creating and continue solving problems.

Some Vue developers also add that Angular is harder to learn than React and React is more difficult to work with than Vue, making Vue the default best choice for some. Developers who feel this way still praise Vue for supporting advanced use cases and having functionality (e.g., lists) that some frameworks don't have. The Vue developers I've spoken to seem pretty bullish on the upsides Vue offers their work.

Gatsby

Whereas Vue is used to build single page apps and web interfaces, Gatsby is used to create static and responsive websites. Gatsby adopters are saying that they're having a great time building static sites with low computational overhead, solid caching, and great performance. Gatsby also makes creating cross-browser progressive web apps easier for them. It seems to be developing a reputation as a beloved JavaScript alternative (or analogue) to the excellent Ruby-based static site generator Jekyll.

The Importance of Testing

Last, and on a non-framework-related note, many developers will rightfully say that every programmer should be able to write testable code and be able to demonstrate that they can do so. This is especially important for developers who aspire to lead development teams, because testable code leads to fewer bugs, regressions, and other problems that get in the way of consistent, reliable, scalable user experiences. In other words, if you want code that performs well, you have to test the code well also. Generally speaking, it's probably wise to invest time understanding topics like manual and automated testing, the tools to use for both, and how to write good tests with such tools.

Accordingly, there's a growing need for JavaScript-specific unit testing and automated software testing knowledge, because with the growth of JavaScript, more JS developers are advancing in their professions. As they become more senior, they are being gauged in part on whether or not they can write and ship code that can be continuously tested and improved.

So what are JavaScript developers saying about testing? That being able to use tools like Jest to test their Vue apps, and state management libraries like Redux to make their code more testable from the get-go, is important to their development work. That their industry peers need to know about general and JavaScript-specific unit testing, performance testing, automated testing, and QA. Unfortunately, I've also heard that there isn't yet the same volume of quality learning material available for testing as there is for technology areas like Docker, Kubernetes, cloud infrastructure, and web app architecture—but hopefully this is about to change. For example, in the last few weeks, several developers (which we call Authors on the Educative learning platform) have told me they plan to create courses dedicated completely to testing.

Want to learn more about JavaScript testing? See if Testing Vue.js Components with Jest or Learn Vue.js from Scratch: Building & Testing a Movie App can help.

Now that we're on the topic of advice from developers to developers, let's see what my JavaScript contacts are learning about and think others should be too.

What JavaScript Developers Say JavaScript Developers Need to Succeed

I've saved the best part of my share for last: what JavaScript developers throughout the world feel their peers should be learning in order to stay ahead and advance the art.

The first perspective JavaScript developers have shared is that if you're switching from strongly typed languages like Java, Kotlin, or Objective-C to a weakly (loosely) typed language such as JavaScript, it can be difficult to make the context-switch. The learning curve for JavaScript can therefore be steep, even for seasoned developers, so invest time into learning how to make that switch, and develop the mental models needed to make the most out of JavaScript. This is an important point for both newcomers to JS and experienced developers looking for fresh challenges.

Some JavaScript developers also argue that their peers from non-traditional backgrounds who learn JavaScript without formal training in computer science will benefit from making time to learn formal language theory. The view here is that developers who self-teach JavaScript at some point need to tussle with formal language concepts, after which they can push JavaScript to its true limits and advance further and faster in their programming careers. I like points of view like this that respect the intrinsic hands-on, learn-by-doing nature of software development while also acknowledging that conceptual theory can help developers transform what they're able to do with their skills. This seems like a balanced strategy.

On a third and more tactical note, multiple developers have mentioned how important it is to understand and implement promises, which are objects you can program today that are capable of returning values in the future. Knowledge of promises—what they are, how they work, when to use them, and why they're powerful—has been described as a must-have in every JavaScript developer's toolkit.

Here are a few more examples of areas JS developers are finding valuable to learn about and recommend to others for further study:

web components & web sockets
progressive web apps (PWAs)
serverless backend frameworks (in Node)
JavaScript-specific interview skills

The "Five-figure Salary Impact" of Strong Interview Prep

I want to highlight that last one. For a lot of JavaScript developers, building amazing applications and becoming known and respected in their professional communities is its own reward, but if you're spending years of your life working hard to become great at what you do, then you naturally want to be well-compensated for your skills. As JavaScript developers climb career ladders and begin to field job offers from multiple companies, solid interview prep can actually make a big difference not only in reducing the time spent interviewing but also in enhancing the compensation packages and final offers extended. I've heard straight from developers that this can make on the order of a "five-figure impact": $$,$$$ more in salary for crushing your interviews. Our courses related to coding interviews, systems design prep, and data structures and algorithms for whiteboarding exercises are popular sellers for this reason.

In Conclusion

The global JavaScript landscape is large, varied, and filled with talent, ideas, and approaches. Developers and engineers in this space have diverse perspectives on how to build applications for web and mobile, on which approaches and frameworks to use, and on how to leverage related knowledge and tools to create awesome things. But every JavaScript developer I've spoken to is unified in this: they all have a passion for JavaScript itself, for continuous learning and experimentation, and for helping others grow along with them.

That about covers it for my first "Conversations with the World's Developers". If you'd like to stay in touch as I learn more from talking to the world's devs in JavaScript and many other languages and frameworks, shoot me an email or follow me on Twitter @alexoeducative. My team can be found at @Educativeinc as well. And if you want to see why 100,000 developers and engineers rave about our courses and tutorials and what our learning material is doing to advance their learning and their careers, check us out at Educative.io.

Teach Our Learners-Your Peers-What You Know

Also, if you have software development experience in JavaScript or in a language, framework, or topic discussed in this post, and if you think you'd like to teach a course on our platform, go ahead and send me a message. We have integrated compilers, an in-browser IDE, and a platform where students don't need to download anything: they just buy your course and start learning right away. Our content creation tools are

welcoming (you've never built a course before? We've got you)
text-based (you don't have a nice mic, an expensive camera, or video editing software? That's okay, your knowledge and a keyboard is plenty)
accompanied by tons of free support from us during your content creation process to make sure your students end up with a great learning experience (you're not on your own :))

We'd love to have you join us as one of the first 100 developers in the world to release courses on Educative. Get in touch.

I'll continue having Conversations with the World's JavaScript Developers, so see you in about six months for Part 2! Thanks for reading.

Appendix: JavaScript-Related Resources Mentioned

Liked this article? Heart and retweet this on Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1150192107597918208-257'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1150192107597918208&theme=dark" }

A Learning Path from C++ to ASP.NET Core

Alex Ortiz — Wed, 19 Jun 2019 00:44:33 +0000

A contact of mine recently asked me a question. They wanted to know how to learn web development with ASP.NET Core 2.1 if they know some C++ but aren't yet familiar with the .NET framework. They asked me if I could suggest a possible learning path for them. So I reached out to some of the developers on my team: if someone knows C++, what are a few of the stepping stones to .NET?

One of my teammates suggested the following.

C++ --> C

Although the .NET framework supports many languages, C# is the language most widely used with it. For example, ASP.NET is specifically a framework for building web applications and services in .NET and C#. Learning the basics of programming in C# and how C# differs from C++ is therefore an essential first step.

Web Development

The learner should also then invest time in learning about web development: client-side frameworks, server-side frameworks, Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), how JavaScript is used alongside HTML and CSS to build web pages, and related web development concepts together form a layer of knowledge on which to build .NET-specific learnings.

.NET --> ASP.NET --> ASP.NET Core

Having laid this initial foundation of C# and web development basics, it becomes useful to spend time with the .NET framework, as well as the usage particulars of ASP.NET. The latter is a server-side framework that is itself part of the .NET framework and is/was the progenitor of ASP.NET Core. The key thing to keep in mind here is that there are many frameworks and libraries available for .NET, and if you start learning about all of them, it can become overwhelming. So a person just starting out with .NET and wishing to build web apps with that framework should focus on how to use ASP.NET Core but without going too deep into the gritty details of .NET vs ASP.NET for now.

After becoming familiar with the basics of how ASP.NET Core is used to build web applications and after taking tutorials, even simple ones such as Microsoft's "ASP.NET Tutorial - Hello World in 10 minutes", the newcomer to ASP.NET Core should know enough to create a very early map that they can use to determine where to turn to next.

All great journeys start small and somewhere. I hope this helps my contact who asked this question and helps you, too, reader!

Till next time.

DEV Community: Alex Ortiz

docker learn #07: A Tiny Post about Image Size & Run Times

Alpine Builds and Runs so QUICKLY

docker images = docker image ls

docker learn #06: Hello Python in Alpine

Installing a Base Image...but Which One?

Using -ti To Run an Interactive Terminal

Adding Python3 with the Alpine Package Manager, apk

Actually Running Python3 in Shell Mode

Taking on a Small Python Challenge

Challenge #1: World, Can You Hear Me?

Challenge #2: Some Maths and Physics

Wrapping Up

docker learn #05: An Interesting --Help Quest

What does --rm do?

When to gladly ask for --help

Where to, From Here?

This Week's Docker Answer Roundup

On deploying AI models using containers

On using multiple containers for a web app

On the future of container virtualization

On image registries

On docker push

On whether or not programmers should learn about orchestrators

Helpful Resources

docker shoutout

docker learn #04: Hanging Out with Ubuntu

Hanging Out with Ubuntu

Uh-oh: Where's that Container?

Ah, There it Is

docker shoutout

docker learn #03: Learnings from Silicon Valley

Everything I Learned about Docker in Silicon Valley Last Weekend

Container Adoption Skyrocketed in the Last Three Years; May Double in the Next Three

A Little Go History, and its Choice for both Docker and Kubernetes

Alternatives to Docker?

To Understand Docker Security, Understand Linux Security

Some More TidBits

This Week's Docker Answer Roundup

On the purpose of Docker

On what Dockerfiles are for

On the difference between two similar-looking docker commands

Some Helpful Resources

docker learn #02: Package Managers

A New Learning: Package Management

My Answer Roundup

On the role of Docker Compose vs that of a Dockerfile

On choosing base images for Dockerfiles

On what Docker images are

On why Alpine is popular as a Linux distro

On Netflix's lack of Kubernetes

On what makes Kubernetes useful

Some Helpful Resources

docker learn #01: My Learning Journey with Docker Begins!

On Learning Openly

What I've Learned So Far: The Basics and Some Simple Commands

Basic Knowledge

A Few Important Basic Commands

Bonus: MAINTAINER vs LABEL

Some Helpful Resources

Conversations with the World's JavaScript Developers Part 1

What Keeps Coming Up in Conversation?

How is JavaScript Being Used?

Why Do JavaScript Developers Love JavaScript? :)

What JavaScript Developers are Saying about...

TypeScript

Elm

Vue

Gatsby

The Importance of Testing

What JavaScript Developers Say JavaScript Developers Need to Succeed

The "Five-figure Salary Impact" of Strong Interview Prep

In Conclusion

Teach Our Learners-Your Peers-What You Know

Appendix: JavaScript-Related Resources Mentioned

A Learning Path from C++ to ASP.NET Core

C++ --> C

Web Development

.NET --> ASP.NET --> ASP.NET Core

`docker images` = `docker image ls`

Using `-ti` To Run an Interactive Terminal

What does `--rm` do?

When to gladly ask for `--help`

On `docker push`

Bonus: `MAINTAINER` vs `LABEL`