Analysis of the reasons why the sshd is not required to run in Docker container _docker

When you start using Docker, people often ask: "How do I get into the container?" "And others will say" run an SSH server in your container. " However, from this blog post you will learn that you do not need to run the sshd daemon to enter your container. Unless, of course, your container is an SSH server.

Running an SSH server is taken for granted because it provides a convenient way to enter a container. In our company basically everyone has used at least one SSH. A large proportion of us use it every day, and they are familiar with public and private keys, password-free logins, key proxies, and sometimes port forwarding and other infrequently used features. For this reason, it is not surprising that you are advised to run SSH in a container. But you should consider it carefully.

Assuming you are assuming a docker image of a Redis server or Java WebService, I will ask you the following questions:

What do you need to do with SSH? Generally, you want to do a backup, check the log, or restart the process, adjust the configuration, and possibly use GDB, strace, or other similar tools to debug the server. Then we'll look at how we don't use SSH to do these things.

How do you manage your keys and passwords? In general, you can either write them in your mirror or put them in a volume. Think about what you would do if you were to update the keys or passwords. If you write them in a mirror, you need to rebuild the image, redeploy them, and then restart the container. This is fine, not the end of the world, but this is not a tall way. Putting them on a volume and managing them by managing volumes is much better than the previous one. This approach is available, but there are serious flaws. You have to make sure that the container does not have write access to the volume, or that the container may break the key (which lets you go into the container later), and that if you use a volume to share it with multiple containers, things will get worse. Without SSH, shouldn't we have one less thing to worry about?

How do you manage security upgrades? The SSH server is safe, but there are still security issues and you will have to upgrade all the containers that use SSH when necessary. This means a lot of reconstruction and restart. In other words, in time you have a simple and small memcached service, you still have to ensure timely security updates, otherwise sink may be destroyed in the nest. So still this sentence, if not ssh, we are less a need to worry about it?

Do you need to "install only one SSH server" to achieve your goal? Of course not. You need to install Process Manager, such as Monit or supervisor. This is because Docker itself will only monitor a process. If you need to run multiple processes, you have to add a layer above to look at their applications. In other words, you are complicating the simple question. If your application stops (normal exit or crashes), you must view it from your process management log instead of simply viewing the information provided by Docker.

You can put apps in the container, but should you be responsible for managing access policies and security restrictions at the same time? In small organizations, this is not a matter. But in a large organization, if you are the person responsible for setting up the application container, it is likely that someone else is responsible for defining the remote access policy. Your company is likely to have a strict policy definition of who can access, how to access, or other types of review and tracking requirements. In that case, you are certainly not allowed to throw an SSH server into your container.

But how do I do it ...

Back up my data?

Your data should exist in the volume. You can then use the--volumes-from option to run another container, sharing this volume with the first container. The benefit: If you need to install new tools (such as S75PXD) to save your backed-up data for a long time, or to transfer data to other permanent stores, you can do so in this particular backup container, not in the main service container. It's very concise.

Check log?

Use volume! again If you write all the logs in a specific directory and the directory is a volume, you can start another Log inspection container (using--volumes-from, remember?) And do what you need to do in this. If you need special tools (or just an interesting ack-grep), you can install them in this container so that you can maintain the original environment of the primary container.

Restart service?

Basically all service can be restarted by signal. When you use/etc/init.d/foo restart or service foo Restart, they actually send a specific signal to the process. You can use Docker kill-s <signal> to send this signal. Some service may not listen to these signals, but can accept commands on a specific socket. If it is a TCP socket, it is only necessary to connect over the network. If it's a UNIX socket, you can use volume again. Set the control sockets of the container and service into a specific directory, and this directory is a volume. Then start a new container to access the volume, so you can use the UNIX socket.

"But it's too complicated," he said. "-it's not. Suppose your servcie named Foo creates a socket in/var/run/foo.sock and requires you to run Fooctl restart to complete the reboot. Just use-v/var/run (or add Volume/var/run in the Docker file) to start the service. When you want to reboot, use the--volumes-from option and overload the command to start the same mirror. Like this:

# starting the service 
cid=$ (Docker run-d-v/var/run fooservice) 
# Restarting the service with a sidekick Contai Ner 

It's simple!

Modify my configuration file

If you are performing a persistent configuration change, you'd better put his changes in image, because if you start a container again, the service will still be using the old configuration and your configuration changes would be lost. So, there is no SSH access for you! "But I need to change my configuration while the service is alive, such as adding a new virtual site!" "In this case, you need to use ... Wait for ... volume! The configuration should be in volume, and the volume should be shared with a special purpose "configuration Editor" container. You can use anything you like in this container: SSH + your favorite editor, or a Web service that accepts API calls, or a timed task that crawls information from an external source; In addition, separation of concerns: one container runs the service, and the other handles configuration updates. "But I made a temporary change because I was testing a different value!" "In this case, view the next chapter!"

Debug my application?

This may be the only scene that needs to go into container. Because you want to run GDB, strace, tweak configuration, and so on. In this case, you need to nsenter.

Introduction Nsenter

Nsenter is a small tool used to enter namespaces. Technically, it can go into an existing namespace or generate a process into a new set of namespaces. "What is a namespace?" They are an important part of the container. Simply put: By using Nsenter, you can go into an already existing container, although this container does not run SSH or any special-purpose daemons.

Where do I get the nsenter?

View the Jpetazzo/nsenter on the GitHub. The simple installation is:

It will install the nsenter into the/usr/local/bin and you will be able to use it immediately.

Nsenter can also be obtained in your distribution (in the Util-linux package).

How to use it?

First, calculate the PID you want to enter the container:

Then enter the container:

In the container, you can manipulate the shell parser. If you want to run a special script or program in an automated way, add it as a parameter to the Nsenter. It works like a chroot, except that it uses a container instead of a simple directory to work.

How about remote access?

If you need to enter a container from a remote host, there are (at least) two methods:

SSH into the Docker host and use Nsenter;

SSH enters the Docker host, authorizing the Esenter command (i.e., nsenter) with a special key parameter.

The first approach is relatively straightforward, but requires root access to the Docker host (not very well from a security standpoint). The second method uses the command= mode in the Authorized_keys file in SSH. You may be familiar with the "classical" Authorized_keys file, which looks like this:

Ssh-rsa aaaab3n ... qoid== Jpetazzo@tarrasque

(Of course, actually a real key is very long, and it usually takes up several lines.) You can also enforce the use of a proprietary command. If you want to view the memory on your system that can be used effectively on a remote host, you can use the SSH key, but you will not want to hand over all the shell permissions, you can enter the following in the Authorized_keys file:

Now, when connecting with a proprietary key, replace the obtained shell, which can execute the free command. Otherwise, you can't do anything else. (Typically, you might also want to add no-port-forwarding, and if you want more information, you can view the Authorized_keys (5) Manual (Manpage).) The key to this mechanism is to separate responsibility. Alice placed the service inside the container; she did not have to deal with remote access, landing and other matters. Betty adds an SSH layer, which is used under special circumstances (debugging strange problems). Charlotte will consider landing. Wait a minute.

Summarize

Is it really a mistake to run an SSH server in a container (uppercase W)? To be honest, it's not that serious. This is even more convenient when you are not visiting the Docker host, but it still requires a shell in the container. In addition, there are many ways we can run an SSH server in a container and get all the features we want, and the architecture is very clear. Docker allows you to use any workflow that works best for you. But before doing this, quickly step into the popular phrase "My container really is a small VPS", please note that there are other solutions so you can make a sensible decision.

The above mentioned is small set to everyone introduced in the Docker container does not need to run sshd reasons, I hope to help you, if you have any questions please give me a message, small series will promptly reply to everyone. Here also thank you very much for the cloud Habitat Community website support!