How to easily deploy applications with free https in docker containers

For today a lot of applications are deployed to cloud hosting, but (but, there are always, but) this solution is not cheap. The best option for creating good infrastructure in own virtual machines are dockers. They can host multiple applications in total separately way.

In this article, I want to present how to easily create docker infrastructure for hosting a few applications in one server. For this particular sample, I will use ready WordPress docker image (but it can be also custom applications written in .Net or Java).

Requirements.​

• Server,
• Domain (with configured record A to server IP address),
• Installed docker support in the server (HowTo),
• Docker image to host.

Let’s start.​

Firstly, for handling a lot of applications by this same ports 80 & 443 (http, https), You must configure Reverse Proxy mechanism. It will be responsible to dispatch requests by domains to special containers. The best solution here will be special configured Nginx reverse proxy container (bbtsoftwareag/nginx-proxy-unrestricted-requestsize:alpine). This container also doesn’t have request size limit, so it’s possible to upload files by it without any restrictions!

docker run --detach \
    --restart=always \
    --name nginx-proxy \
    --publish 80:80 \
    --publish 443:443 \
    --volume /etc/nginx/certs \
    --volume /etc/nginx/vhost.d \
    --volume /usr/share/nginx/html \
    --volume /var/run/docker.sock:/tmp/docker.sock:ro \
    bbtsoftwareag/nginx-proxy-unrestricted-requestsize:alpine

Upper docker command is responsible for starting our Super Reverse Proxy Hero. Some details:

• –detach – start docker in background mode (like a windows service),
• –restart=always – when our server will be restarted, this container will wake up fast like fire ;-),
• –name – just container name, by this we can identity it,
• –publish – very important thing for this image. This container will be out gateway between real-outside world & our internal, secure docker infrastructure. So all web requests (http / https) must be published to outside, btw. Check Your firewall settings ;-).
• — volume – shared disk space to keep data like ex. ssl certs.

Okey, so now we have configured http server, what we need more to be happy? Free, auto-refresh ssl certs! To achieve them, we must create another… docker (yeey). This image (jrcs/letsencrypt-nginx-proxy-companion) will be responsible for generating SSL certificates by let’s encrypt mechanism.

docker run --detach \
 --restart=always \
 --name nginx-proxy-letsencrypt \
 --volumes-from nginx-proxy \
 --volume /var/run/docker.sock:/var/run/docker.sock:ro \
 --env “DEFAULT_EMAIL=you-magic@email.com” \
 jrcs/letsencrypt-nginx-proxy-companion

This piece of code is responsible for creating that pretty, auto-refresh SSL mechanism. Details almost like in the previous code sample. The additional thing is only the environment variable for the share Your email with let’s encrypt companion.

This dockers should be created only once, at begin of journey.

Ready to host!

The last ToDo thing is start application image, in our case, it will be simple wordpress application. Firstly, we must create MySql docker image.

docker run --detach \
 --restart=always \
 --name=mysql \
 --volume=/etc/mysql/conf.d:/etc/mysql/conf.d \
 --volume=/etc/mysql/data:/var/lib/mysql \
 --expose 3306 \
 -e MYSQL_ROOT_PASSWORD=passw \
 -e MYSQL_USER=wordpress \
 -e MYSQL_PASSWORD=wordpress \
mysql:5.7

Our internal mysql database was created successfully, it’s available only in internal docker network by exposed port 3306. Now, we must create our main quest, WordPress.

docker run --detach \
--restart=always \
--name=the-worst-dev \
--volume=/etc/hosting/the-worst-dev/html:/var/www/html \
--expose 80 \
--expose 443 \
-e WORDPRESS_DB_HOST=mysql:3306 \
-e WORDPRESS_DB_USER=root \
-e WORDPRESS_DB_PASSWORD=passw \
-e WORDPRESS_DB_NAME=theworstdev \
-e VIRTUAL_HOST=the-worst.dev \
-e LETSENCRYPT_HOST=the-worst.dev \
wordpress:latest

The most important things for our case are 2 last parameters.

• –e VIRTUAL_HOST=the-worst.dev – this parameter tells our Reverse Proxy Nginx container, what requests should be dispatched here.
• -e LETSENCRYPT_HOST=the-worst.dev – here we have configuration for creating SSL certs for https access.

Don’t forget about expose ports 80 / 443! This rule is important to communication between Nginx and WordPress container.

How it’s works?

As You see for all infrastructure we must have n + 2 docker containers. Every container with n-category must have information about his domain for correct redirection & create SSL. All requests are handled by 2 dockers, the first it’s Nginx, the second it’s destination container. Nginx can be bottle neck, but if You have a lot of requests You must scale Your solution for example by Kubernetes, but this is different story 😉

It’s all, Thanks for reading ;-)!

Ps. It’s my first post in life…