If we don’t, we’ll see errors in our deploy, showing the process ran for “< 1 second”, meaning it went right into the background, which supervisor sees as an error. This means they need to be running in the foreground. When working with Docker, we need to make sure none of our programs are running in daemon mode. If a service goes down, supervisor will then restart it so the service is always running. When you use supervisor, you set a base configuration, then set the configuration for each program you want to run. Supervisor is a great complement to Docker, giving anyone the ability to run multiple light services within a single container. On the very last line, we are using supervisor as an entry point using CMD, which causes supervisor to become the foreground process to keep the container alive. ![]() Dockerfile FROM nginx:alpineĪpk add openvpn rsyslog net-snmp net-snmp-tools iproute2 bash supervisor curlĪDD nf /etc/nginx/conf.d/nfĪDD nf /etc/sysctl.d/nfĬMD /usr/bin/supervisord -c /app/nf These are present within a real-world docker build, and showcases how a container can run multiple services. This file shows multiple services, but keep in mind that snmpd, rsyslog, and nginx are not required for OpenVPN to work. Below we see the Dockerfile used for this setup. etc/sysctl.d/nf _forward=1Īll that’s we have left to do is to set supervisor as our command which starts with the container. Now that we have this file in place, network forwarding is automatically applied every time the container starts. To make this automatic, we copy the nf file to the container in the Dockerfile. We do this by placing the nf file, which enabled forwarding, in the sysctl.d folder. In order to forward our traffic to the tunnel, we need to enable forwarding through sysctl. Once we can establish a connection with OpenVPN, we need to verify it can go through the tunnel. When we test our build locally, we can provide the device from our own local system like so: $ docker run -cap-add=NET_ADMIN -device /dev/net/tun:/dev/net/tun -i -t openvpn-test /bin/sh In case it doesn’t exist, we create a placeholder during the build process: RUN mkdir -p /dev/net & \Įven if it is, we create it so we can build the container image. Depending on the host, this device may already be available. Since we are wanting to use OpenVPN, we will need access to a tun device for the tunnel. If you are looking to setup lots of OpenVPN clients, be sure to check out our OpenVPN Client Management Script. By doing this, we only need one command to copy everything to the /etc/openvpn folder. ![]() The vpn folder holds the nf file, as well as the required keys and certificates needed for OpenVPN. We place all of the OpenVPN files into a local folder named vpn. Then we replace the configuration files with a custom local copy. ![]() Dockerfile SetupĪs usual, we add the required packages for OpenVPN as well as supervisor for our process control. So we needed a custom OpenVPN tunnel to securely pass sensitive data to remote logging servers. Because of additional features provided on the host, our company uses a external host for the proxy. We needed our Nginx reverse-proxy to pass analytical data to a centralized database server. The idea behind the container build was out of need. Let’s look at how to create this container using Alpine Linux, and how to use the power of supervisor to run multiple services. At first glance this would seem like a simple process, but the reality is that it requires a bit more effort to create. The difference from other containers, was the need for an automatically active OpenVPN connection that would start with the instance. ![]() I recently found myself needing a IDS node container for internal use that would automatically connect to a centralized logging server. Docker is becoming more and more commonplace with custom instance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |