No Internet access from your Docker container? Check this out!

After a recent update I started having issues with my containers that hosted apps which were accessing the outside world periodically. At first I couldn’t understand where the problem is. I’ve been checking a lot Github issues without success and finally I remembered that I’ve made an update to my host which updated the kernel.

What I needed now is to find a way to boot with an older kernel selected by default. I started looking in Stackoverflow pages and blogs and found a way to set any kernel that I already have installed as the default one.

Here are the steps I took to fix my problem(my host is running Ubuntu linux):

  • check the /boot/grub/grub.cfg file for all available options you have. The name of every kernel installed is there. Pick one that is older than the latest installed. You have to look for entries like: “menuentry ‘Ubuntu, with Linux 3.13.0-113-generic'”. You will use the “Ubuntu, with Linux 3.13.0-113-generic” part
  • next open the /etc/default/grub file and look for the GRUB_DEFAULT entry
  • combine your kernel config name from point one from above with “Advanced options for Ubuntu” or “Previous Linux versions” for older Ubuntu versions (<14.04). You’ll have to have a similar string like this one now: “Previous Linux versions>Ubuntu, with Linux 3.13.0-92-generic”. Set GRUB_DEFAULT to this string like: GRUB_DEFAULT=Previous Linux versions>Ubuntu, with Linux 3.13.0-92-generic
  • you can use numeric values for GRUB_DEFAULT but it’s not recommended as the number will point to a random kernel config after the next update
  • save, run sudo update-grub and restart

Now you should have an Internet access from inside the Docker containers. This is just a temporary solution so don’t leave it like this, especially running with an older kernel. Better check you configuration and even reinstall everything on your host, use a newer linux distro, etc.

Source

Docker 1.9.0 and the new network configuration

Docker 1.9 is here and it introduces a new way to handle the networking between containers.
Because docker containers should live a short live before being replaced with their new versions one should ask himself do we really need the static IP that was existing until now and assigned to the Docker’s bridge? The usual IP you will see was 172.17.42.1.

After upgrading this IP will be gone. Instead other IPs will be created dynamically. Of course there will be another IP like 172.17.0.1 assigned to the docker0 bridge. You can use it if you are brave enough but better not.
However if you need a quick fix before going to bed you can use the Docker’s –bip parameter to set the bridge IP back to 172.17.42.1.

Another way is to go back to version 1.7.1 using your OS’s package manager or direct install/compile.
Later when you decide to start using Docker’s networking the right and better way, you can start from here.

How can you tell if a programmer knows Docker in 5 questions? | The Snap.hr Blog

Source: How can you tell if a programmer knows Docker in 5 questions? | The Snap.hr Blog

I struggled only on the last question about the difference between AUFS and DeviceMapper but these kind of questions always help me to find what I have to know to pass them. And I love to learn new things!

Docker container with broken Mysql database. Lesson learned. Backup often. Backup your DB or at least the container.

I’ve been updating lxc-docker every time a new version is suggested by my Linux OS. While the apt-get install lxc-docker was working it stops and starts again with the new Docker version. Usually nothing happens with the containers being forced stop and started that way but today I’ve had a broken Mysql DB for this WordPress installation and couldn’t restore it from its data directory no matter what I’ve tried. Because I didn’t want to loose more time I decided I can restore previous commits to the same image that container is running from.

I’ve found the docker history imagename command and tried it. I’ve added a couple of commits to this image and I’ve had a couple of lines with the history commands. I’ve picked the commit before the broken state and ran the wordpress container the same way I am running it with the :latest tag but this time used the commit ID. It ran well and I’ve made a commit from it to its image. Stopped and removed the wordpress container and ran it with the usual command using the latest imagename command this time and now it’s running well.

Now I know that when I am going to stop the images and update the Docker executable I must backup the databases, files and commit the latest state of the containers (not much by the rules because the container should be able to be rebuilt at any time keeping the data outside the container).