Articles, notes and random thoughts on Software Development and Technology
By default the Docker service listens on a local socket. If you want to access the Docker service api remotely, you need to configure the service to listen on a port as well.
On Ubuntu 16.04, edit /lib/systemd/system/docker.service and change this line:
ExecStart=/usr/bin/dockerd -H fd://
to
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2376
Reload the systemd config:
sudo systemctl daemon-reloadand restart the service:
sudo systemctl restart docker.serviceMore info here.
Trying to start the Dockerd service on an Ubuntu 14.04 server I ran into ‘sudo service docker start’ hanging, and in the logs seeing this message:
Mar 4 17:12:07 vps kernel: [58270.204343] aufs au_opts_parse:1155:dockerd[12023]: unknown option dirperm1 Mar 4 17:12:49 vps kernel: [58311.799010] init: docker post-start process (12015) terminated with status 1
This is described in this post here and here.
In the Docker CE for Ubuntu instructions, there’a a note for installing additional aufs support for 14.04 here:
sudo apt-get install \
linux-image-extra-$(uname -r) \
linux-image-extra-virtualNote the Docker CE for Ubuntu install docs say for 16.04:
For Ubuntu 16.04 and higher, the Linux kernel includes support for OverlayFS, and Docker CE uses the
overlay2storage driver by default.
In this particular case I had mistakenly setup this VM from a 14.04 template, and I really wanted to be running 16.04. With 16.04 and the latest Docker install per the installed steps here, I didn’t run into this issue.
Assuming you already have an installed an running Gitlab server, you need to install and configure a GitLab runner:
Install gitlab-runner: https://docs.gitlab.com/runner/install/linux-repository.html
Run the gitlab-runner shell setup, described here: https://docs.gitlab.com/ce/ci/docker/using_docker_build.html
Get the registration token from the Settings / CI/CD Settings page.
You can now use docker commands in the script section of your .gitlab-ci.yml file defining your pipeline.
I’m in the middle of migrating this existing site to Docker containers and moving to a new VPS host. Part of my motivation for the move is to capture the customized configs for each of the servers, so I can easily move the whole deployment between a test environment and a production deploy. What’s prompting this is the realization that the majority of the performance tweaks I made during the first native install I have captured in various blog posts here, but to recreate these install steps I would need to go back to each of those articles and get the details in order to repeat them elsewhere. That’s not a particularly repeatable process.
I’m close to switch from my current non-Docker install (here, as of 2/27/18) to my test install now running on Docker. I’ll share more about how that is configured in future posts, but I just wanted to capture one nginx + php5-fpm specific config that had me stumped for a few days.
There’s many options for configuring the worker processes for nginx and php5-fpm. php5-fpm itself has a number of modes that control how it manages it’s worker processes. By default the process manager is ‘dynamic’ (pm = dynamic). This creates processes to handle incoming requests based on the other related config options (max_children, start servers, min_spare_servers, max_spare_servers etc).
On my current site based on recommendations I changed this to pm = ondemand in order to minimize memory usage on my 512MB VPS. One other param though had an interesting effect:
pm.process_idle_timeout = 10s;
This keeps a process alive for an additional 10s after it’s finished the current request. This seems to have an impact on the responsiveness of the WordPress site, as without this there seems to be a noticeable lag of 3-4 seconds before responses start to come back to the browser, presumably because new worker processes are needed to restart to handle the next request – by keeping them up after the last request there no lag to restart a new process.
I was almost at the point of making a no-go decision based on the laggy performance, but adding this one param has fixed the laggy behavior, and now I’m looking all set. Given that I’ve jumped from a 512MB VPS to a 4GB VPS, I’m less concerned about keeping memory usage to a minimum this time so I haven’t changed from dynamic to ondemand in the Docker config for my new nginx + php5-fpm config, but this one param is worth knowing about.