In order to be able to manage our infrastructure and applications, we had the idea of using Docker Cloud. However, since we have a lot of virtual machines hosted on Azure, the costs of doing so would increase quite fast.
As we hunted around for a solution, we found Rancher fit our needs as we could manage and provision docker-machines from Azure virtual machines. Getting it properly set up, however, was not an easy task. Not because of the product itself but because of all the dependencies around it.
I must mention that we really enjoy all the functionalities that Rancher offers and also the speed at which they reply to any issues posted on their github repos. Thanks a lot for your hard work and your great product! 🙂
- The reference material for this article can be found here
- We’ll base the haproxy and letsencrypt services on this previous article
The Services Definition
version: '2' services: haproxy: image: m21lab/haproxy:1.6.2 links: - letsencrypt - rancher ports: - '80:80' - '443:443' restart: always volumes: - /var/run/docker.sock:/var/run/docker.sock volumes_from: - letsencrypt letsencrypt: image: m21lab/letsencrypt:1.0 environment: DOMAINS: 'YOUR_DOMAIN' EMAIL: 'RECOVERYEMAIL@YOUR_DOMAIN' LOAD_BALANCER_SERVICE_NAME: 'haproxy' OPTIONS: '--staging' db: image: m21lab/rancher-mysql:5.7 restart: always environment: - MYSQL_ROOT_PASSWORD=MYSQL-ROOT-PASSWORD - MYSQL_DATABASE=rancher - MYSQL_USER=rancher - MYSQL_PASSWORD=MYSQL-RANCHER-PASSWORD volumes: - ~/rancher-mysql-data:/var/lib/mysql rancher: image: m21lab/rancher:1.3.0 links: - db expose: - 8080 restart: always environment: CATTLE_DB_CATTLE_MYSQL_HOST: db CATTLE_DB_CATTLE_MYSQL_NAME: rancher CATTLE_DB_CATTLE_USERNAME: rancher CATTLE_DB_CATTLE_PASSWORD: MYSQL-RANCHER-PASSWORD MYSQL_SERVICE_NAME: 'db' VIRTUAL_HOST: 'LETSENCRYPT_DOMAINS_ENV_VAR, https://LETSENCRYPT_DOMAIN_ENV_VAR' #Redirects HTTP => HTTPS FORCE_SSL: "true"
HAProxy is the load balancer which also handles the SSL traffic. It reconfigures itself when Let’s Encrypt certificates are received. More information in the previous article.
Let’s Encrypt is used to generate valid CA signed SSL certificates for the domain hosting the registry. More information in the previous article.
All that’s needed is to create a database name, root password, username and user password. Then add a volume to store the database itself and it’s configured. The rancher database will be initialized if it’s not already existing or updated when there is a version upgrade.
The rancher service configuration is mostly:
- Linking the db service
- Setting environment variables to map database, database username, and password
- Setting environment variables to receive traffic from the haproxy service and to force it to be using SSL
- Setting the MYSQL_SERVICE_NAME environment variable which will be used by the image to ensure the database service is up and running prior to starting the rancher service
How to start it
If you just want to run it locally, you won’t want to use the haproxy/letsencrypt setup, so just add a port mapping on the rancher service:
services: rancher: ports: - '80:8080'
docker-compose up -d db rancher
Publicly accessible machine
Important Assumption: You are running those docker commands from (or using docker-machine as explained in this article) a machine publicly accessible by the domain you want to get SSL certificates for.
- Update the letsencrypt service’s DOMAINS environment variable
- Update the rancher service’s LETSENCRYPT_DOMAINS_ENV_VAR with the same domain
docker-compose up -d
Minimum 1Gb of RAM for the VM: It matters!
We used an Azure Basic AO instance with version 1.1 and it was running smoothly even though the minimum requirements were 1Gb RAM. Once we upgraded to 1.3, we did not think about upgrading the VM. After all, it was working before! At some point, the system just got really slow until it rebooted all by itself without any obvious logs from Rancher or the Azure portal.
Self Signed Certificates: great! SSL, but …
When we started to configure this server, we used a self-signed certificate. This lead to multiple problems because:
- Every host added to Rancher would have to be manually configured to trust the self-signed CA certificate.
- Not even the host itself needed to be configured, but a specific folder used as volume by the rancher/agent container needed to be updated too: /var/lib/rancher/etc/ssl/ca.crt
- NOTE: The doc was only updated in version 3, it wasn’t mentioned in version ≤1.2
- The Docker registry was also using a self-signed certificate, which forced us to add our own registry as an “insecure registry” when creating a host which modifies the parameters passed to the docker-engine the host runs
- Our NPM repository was also using a self-signed certificate which was not trusted by any of the containers and all the projects were modified to include the strict-ssl=false configuration in the .npmrc file
- Every user of the Rancher portal would have to trust the company’s self-signed certificate
Provisioning Azure VM from Rancher 1.1 to >1.1
We started using rancher/server version 1.1.0 a while back, and when we tried to provision an Azure virtual machine, it was required to create an SSL certificate and upload it to the Azure Management Portal in order to give rancher the rights to provision Azure resource on behalf of our subscription.
Surprise! Once we got that up and running and decided to upgrade to 1.3, this method had changed! Rancher uses the Azure docker-machine driver which now required an Active Directory Application with a Service Account attached which will grant the rights to create resources in the Azure Subscription. Obviously, we need the IT in order to do so since it had to be done in the default Active Directory of the Subscription.
This post originally appeared on Medium.
Insights delivered to your inbox
Subscribe to the dev blog to get the latest insights in IoT, Alexa Skills development, and software development.