Giacomo Vacca

Some time ago I prepared an introductory seminar on Docker, which I called "Docker from scratch". The audience was a local group of heterogeneous developers. As it typically happens, preparing that material was a great opportunity to understand better some of the aspects. I then published the slides in Slideshare. I notice now that they got a decent number of views and downloads, so I'm linking those slides here as well for reference . One big change in respect to 2016 is represented by the choice of abandoning Docker Toolbox in favour of running Docker directly on macOS. I have to say I liked the sandboxing that came with Docker Toolbox, where the docker engine ran inside VirtualBox, now only available for older versions .

One of the handiest features of the docker build system is the caching system. 'docker build' tries to reuse the layers already built until something changes inside the Dockerfile. In this way, we can save several minutes when rebuilding an image if the changes happen further down the list in the Dockerfile. Sometimes, though, we do want to invalidate the cache and ensure the next build won't use it. To do this an option is to pass the '--no-cache' argument to 'docker build'. When dealing with 'apt-get install' instructions though there are other tricks. I found this document on Dockerfile best practices very useful. First of all an observation. If you have 'RUN apt-get update' as a single line of a Dockerfile, followed by the installation of a package, e.g.: RUN apt-get update RUN apt-get install -y nginx then changing the list of packages and running again the build command won't trigger an 'apt-get update': that...

Often things are more convoluted than you expect. Sometimes they are easier than you fear. Here's an example: you're generating files inside a Docker container (with no volumes configured) and you realise you need some of those files available in the host. A simple solution is to use 'docker cp', with a format like docker cp CONTAINER_ID:FILE_PATH HOST_FILE_PATH Official documentation . A Stackoverflow question with more discussions .

There's something about debugging: the more you have experienced finding the root cause of bugs in the past, the highest the hope and confidence you'll squash the one currently under the microscope. You see I didn't mention "fixing" a bug, because I think finding the root cause of any bug has value per se . Fixing them is a separate adventure. Anyway this week I was entirely bamboozled by this: a Docker container was re-deployed with a different networking configuration. In particular, with Compose, I was dedicating a network for that container (let's say 172.18.0.0/24) separate from the default Docker network (e.g. 172.17.0.0/24). In docker-compose.yml: networks:   apps:     driver: bridge     ipam:       driver: default       config:       - subnet: 172.18.0.0/24         gateway: 172.18.0.1 In the "service" definition I just added this: services:   THESERVICE:     ...

I've presented a workshop at Kamailio World 2016 . It focused on tools to help automating the build, deployment and test of Kamailio -based applications using Jenkins , Docker and a few other technologies. It's been also an opportunity to show a sample usage of the new http_async_client module, designed to perform non-blocking HTTP queries from Kamailio. The interested reader can find the slides here: Continuous Integration and Kamailio from Giacomo Vacca And if you have an hour to spare, here's the full video: Any feedback or question you may have, please get in touch. I have a post on the event in progress, but there are so many things to highlight that it will require some more time. Many thanks to Daniel and Elena-Ramona ( more info here ), event hosts, and Pascom.net for video streaming, recording and editing.

This is a topic I really care about. Please take a look at the slides (they are quite verbose) used in a seminar at a local developers group: Docker and Puppet for Continuous Integration from Giacomo Vacca

Docker is an incredibly useful tool to build prototypes of Linux hosts and applications. You can easily build a network of servers inside a single virtual machine, with each server represented by a docker container. Clients can access the services on the same IP address, but different ports. In this post I'd like to talk about a common prototype case in WebRTC  platforms: a WebSocket server. This will be a node.js server and will run inside a Docker container (hosted by an Ubuntu Trusty VM). The server logic can be as complex as you can imagine, but since it's not the point of this post I'll keep it as simple as the server example in the node.js websocket module : The WebSocket server will listen on port 8080, accept incoming connections, send back "something" upon client connection, and log the content of the messages from the clients. We can assume all the files in this article are in the same folder, and we're cd into it. The server logic is...

Just wanted to share what approach I'm following to test Pull Requests for the trulabs Asterisk Puppet module . Run a docker container, choosing the base target distribution, e.g. one of: docker run -i -t debian:wheezy /bin/bash docker run -i -t ubuntu:precise /bin/bash docker run -i -t ubuntu:trusty /bin/bash Inside the Docker container, set up some preconditions: apt-get update apt-get install -y git apt-get install -y puppet apt-get install -y vim Clone the git project: mkdir -p git/trulabs cd git/trulabs git clone https://github.com/trulabs/puppet-asterisk.git cd puppet-asterisk Create a new branch: git checkout -b PULL_REQUEST_BRANCH master Checkout the project from which the Pull Request is created: git pull https://github.com/CONTRIBUTOR/puppet-asterisk.git PULL_REQUEST_NAME Build and install the Asterisk Puppet module built with this Pull Request changes: puppet module build . puppet module install pkg/trulabs-asterisk-VERSION.tar.gz ...

docker containers are very easy to build, and the ability to re-use them is extremely handy. They do require a lot of disk space though, and if like me you need to retrieve some of that space you can delete the containers that are not running with this command: docker rm $(docker ps -a -q) In fact 'docker ps -a -q' lists all the containers, but 'docker rm' won't destroy running containers, and the command above will do the job. You still have the images though (visible with 'docker images'), and each one can be relatively big (> 400MB). I tend not to tag images, so in general I'm interested in the 'latest' ones, or the official ones (like ubuntu:14.04, where ubuntu is the repo and 14.04 is the tag). Anyway even if selecting the "untagged" ones does the job for me, I can clean up the undesired images with: docker rmi $(docker images -q --filter "dangling=true") I've seen other commands just relying on th...

Just a list of docker commands that I've found quite useful so far. List the containers available locally: docker ps -a Just the container IDs: docker ps -a -q Filter the running containers: docker ps -a -q | grep Up or simply: docker ps -q  Build an image: docker build -t <user>/<image name> . Run a container from an image, and execute bash shell: docker run -i -t <user>/<image name> /bin/bash Run a container from an image, in background, linking ports: docker run -d -p <host port>:<container port> <user>/<image name> (You can use -p multiple times, e.g. when the container exposes more than one port) Show logs of running container: docker logs <container id> Stop/start/restart container: docker stop/start/restart <container id> UPDATE - Stop running container with a single command: docker ps -a|grep Up|awk '{ print $1 }'|xargs docker stop  UPDATE - The reason why I'm ...

I've been spending some time with Docker , and since digitalocean provides Ubuntu images with Docker already configured, setting up a new droplet and a few containers with my apps has become a matter of minutes. One of the fist commands you want to run in your Dockerfile is certainly 'apt-get update'. I'm writing this with the hope to save the reader some precious time: if 'apt-get update' fails, you may want to ensure that docker's DNS configuration is complete (and servers are accessible). In my case this meant simply adding the Google DNS servers in /etc/default/docker : DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4" and restart docker with sudo service docker restart This StackOverflow question is related.