Updating infrastructure

 Mon, 16 Jan 2017 16:46:30 +0100 
What happened with the response time of this #Piwik installation? Too bad I will never know.
Is it #Docker? (It was not containerized before)
Is it #MariaDB? (It was MySQL before)
Is it #PHP7? (It was PHP5.6 before)
Is it #Nginx reverse proxy? (There was no additional reverse proxy before)


The new host has just 2 virtual cores instead of 4 before and 3GB virtual RAM instead of 6GB before. It runs on the same virtual environment. The base system was CentOS6, now it is a SIG of CentOS7 Atomic Host.



 Fri, 09 Dec 2016 19:02:47 +0100 
Nearly all web projects are moved to #Docker containers now. The old infrastructure was mostly based on CentOS6/7 and the main reason for this step was the annoyance of legacy #PHP projects and their PHP version requirement conflicts. I don't need a cluster or swarm, so I have a single instance with #CentOS based #Project Atomic only. The dockerized projects include:
static pages with nginx
#TYPO3 7.6
#Drupal 8.2
#Piwik 2.17
#Revive Adserver 4.x
#OXID eShop 4.[9|10]

Here are some completely subjective "best practices":
  • I was a bit disappointed about most available images in Docker's Hub. But make use of the official mariadb, php, drupal, nginx images!
  • Use your Dockerfile and no massive entrypoint scripts.
  • Don't try to build a base images for all your projects, the projects have all too different requirements. Found it much easier to build custom images from the official PHP images directly with only what was really needed for the projects.
  • Think about mail delivery requirements. Does your application requires mail(), or can you configure a SMTP server. Use sSMTP if you need a local MTA.
  • Get your persistent volumes right and use the correct #SELinux labels.
  • A local repository makes deployment much easier.
  • Use #Jenkins to build and deploy new images.
  • Don't use --link, use Docker networks instead!
  • jwilder/nginx-proxy still has some bugs, especially with custom nginx configurations, but a wonderful tool.
  • jrcs/letsencrypt-nginx-proxy-companion and it was never easier to get certificates.
  • Think about reboots. How you want your containers to be managed? Services for systemctl work quite well so far.
  • Redirect your application logs to the right output. Log management I should take a look at again.

Should also get my private projects into containers next.

Tear down docker test containers based on image name

 Thu, 01 Sep 2016 16:49:47 +0200 
Given your #CI generates #Docker images from your Git commits and tags them with something like web01-qa:$BUILD_NUMBER. Right now I can not set a name for the container that gets spun up after every commit, so I needed a solution to tear down the old containers after successful start of a new container based on the image they were created from. This is what I came up with:

docker ps --format "{{.ID}}\t{{.Image}}" | awk -F ':' '/web01-qa/{print $NF, $0}' | sort -r -n | tail -n+2 | awk '/web01-qa/{system("docker stop " $2)}'
Get all running containers, sort them by $BUILD_NUMBER for the image name containing web01-qa, stop all matching containers except the one from the newest image.

Or use docker rm -f if not interested in the old containers anymore.

so many containers ;-)

 Thu, 25 Jun 2015 17:49:07 +0200 
Our docker service was a bit slowly loading...
$ docker ps -aq | wc -l

#Docker? #Jenkins? #WTF?!?

Spinning up a container seems to be much quicker than removing an old container. I started to delete these containers this morning. After 7 hours there are still around 45000 containers left. o_O


 Thu, 04 Dec 2014 11:39:19 +0100 
An alternative for #Docker
#^CoreOS is building a container runtime, Rocket
Rocket is a new container runtime, designed for composability, security, and speed. Today we are releasing a prototype version on GitHub to begin gathering feedback from our community and explain why we are building Rocket.
Why we are building Rocket
When we started building CoreOS, we looked at all the various components available to us, re-using the best tools, and building the ones that did not exist. We believe strongly in the Unix philosophy: tools should be independently useful, but have clean integration points. We hope this is reflected in tools that we build, such as etcd, which have seen widespread adoption and use outside CoreOS itself.

Bosun monitoring & alerting

 Fri, 14 Nov 2014 16:22:13 +0100 
#^Announcing Bosun, our new open source monitoring & alerting system « Blog – Stack Exchange
If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. - Deep Thoughts, by Jack Handey A big part of scaling up an engineering team is getting serious about monitoring and alerts. A good monitoring system collects data from all of your various systems — for example, how...

Sounds quite good. They also have a very interesting looking build system based on #Docker.

Docker, Chef, & Immutable Infrastructure

 Sun, 02 Nov 2014 01:13:33 +0100 
chef-summit-2014 - Wiki for the Chef Community Summit - 2014
Docker, Chef, & Immutable Infrastructure

#Docker #Chef #CM


 Wed, 24 Sep 2014 22:54:02 +0200 
Byebye Veewee hello #^Packer

Packer is a free and open source tool for creating golden images for multiple platforms from a single source configuration.
Quite powerful tool to create automated virtual images for #Vagrant, #Docker and other platforms.
Using btrfs for such images seems not to be a good idea. The same configuration just different filesystems: xfs 400MB, btrfs 600MB image size. o_O


 Wed, 07 May 2014 22:52:16 +0200 
Used #veewee to generate #Vagrant boxes so far. #Packer also looks to be a really interesting tool to generate images for multiple platforms like #VirtualBox, #Docker, #OpenStack, etc. from one source configuration. Also supports several provisioners like #Chef, #Puppet, #Ansible, etc.

Packer is a free and open source tool for creating golden images for multiple platforms from a single source configuration.