How to temporarily fix the message “TERM environment variable not set” while working with a Docker container

Sometimes at least these days with the current version of Docker you may stumble upon the message “TERM environment variable not set”.

This happened to me while being inside a container with “docker exec -ti”.

clear, top, etc. were not working and complaining about the not set variable.

If you execute this while inside the container:

export TERM=xterm

or

export TERM=${TERM:-dumb}

the warnings will stop and you can have the real thing.

Docker image with Jenkins CI and full PHP configuration and tools

See it in action here.

Get the source from Github here.

This Docker image follows the http://jenkins-php.org/ configuration for installing Jenkins CI and the PHP testing tools.

It uses Ubuntu 14.04 LTS image.

The PHP 5.5 PPA by Ondřej Surý is used for the latest version of PHP and its extensions.

For Jenkins the Debian deb repo is used.

The deb mirrors.ubuntu.com/mirrors.txt is used for faster local updating/downloading of the apt packages.

DEBIAN_FRONTEND=noninteractive and apt-get -qq are used for automatic silent installs.

date.timezone=Europe/Sofia and ;disable_functions= are set in php.ini

After Jenkins is installed and needs its first update there is a wait of 60 seconds until the update script is called.

The Jenkins server is first updated before installing the plugins.

Currently these plugins are installed: checkstyle cloverphp crap4j dry htmlpublisher jdepend plot pmd violations xunit.

And these PHP testing tools are installed globally through Composer: phpunit/phpunit, squizlabs/php_codesniffer, phploc/phploc, pdepend/pdepend, phpmd/phpmd, sebastian/phpcpd, theseer/phpdox.

Composer installs the tools in /home/jenkins/.composer and makes all of them available globally in /usr/local/bin/.

Composer is set to use git to fetch the dependencies to avoid the GitHub API rate limits.

Port 8080 is exposed and available. This is the default Jenkins’ port.

The default CMD in the image is: “sh /run_all.sh”

Install

First download the image:

docker pull iliyan/jenkins-ci-php:1.0.0

And run it:

Locally:

docker run -d --name jenkins -p localhost:8080:8080 iliyan/jenkins-ci-php:1.0.0

Visible from outside on a hosting server:

docker run -d --name jenkins -p VISIBLESERVERPORT:8080 iliyan/jenkins-ci-php:1.0.0

Alternative usage of the PHP testing tools:

You can download all of the tools from your project’s composer.json file adding them for example in the dev secion like I did here and here.

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).

Just started learning PhalconPHP

http://phalconphp.com

I just started learning it by reading its online documentation. I will definitely have to find a book about it and there is at least one out there and also I have to pass through all the examples like 10 times until I sit and make something with it. The installation of course is the easiest part, even inside a Vagrant box or Docker.

Preview of Docker Benchmarking at Flux7 | Flux 7

Preview of Docker Benchmarking at Flux7 | Flux 7.

The way I see it, Docker is in a position similar to AWS: revolutionary; easy to get started on; but to enjoy many of the benefits, you need to have someone guide you and ramp you up to really unlock the benefits or use the technology.

History, Logging, and Debugging (SSH, The Secure Shell: The Definitive Guide)

History, Logging, and Debugging (SSH, The Secure Shell: The Definitive Guide).

Found this article while searching for a way to keep the sshd process in the foreground but it’s closed after the client is disconnected. However the article is about logging and is very informative.

Strange hang-ups with Docker

Today I had to change some buffer setting for MySQL in my.cnf.

So I set the new settings and tried /etc/init.d/mysql reload.

This passed successfully but when I went to the running mysql to check the settings they weren’t changed.

So I decided to make /etc/init.d/mysql restart.

Big mistake because the mysqld process was keeping the container from closing. I suspect it stopped mysql and then the container stopped too, there was only one additional sshd process running which I used to connect to the container.

However the DB is in good condition, but what happened after the mysql container closed is bothering me. That’s why they say don’t use it in production! 😉

I’ve executed docker start mysql_container

It started, atop showed me a huge hdd usage for a second and the port was open but I couldn’t connect with telnet or the mysql client. I’ve made one docker commit –run=” mysql_container iliyan/mysql and kill/rm of the current one. Checked the mysql port – it was closed, nothing hanged there. Then ran the iliyan/mysql with bash, started the mysql server from there it started successfully, connecting with the mysql client locally to the server succeeded and then I realized it’s something controlled by Docker that hanged.

So I decided to restart the docker process which restart all of the containers (service docker restart). It restarted, started 3 containers from 5 and I ha to just docker start cont4 cont5 to finish the process.

Now everything is working well again but this one have to be monitored. Who know if this is not going to happen again or every time a long running container is restarted.

Update: Some time passed and the things were mostly good. However from yesterday I wonder why the hell the page visits lowered to one of my site and decided to check the firewall:

iptables -L

What I saw from the first look is that I have too much repeating IPs of the containers. I also remember that the last time I restarted the mysql percona container (I keep a big DB inside, no volumes, so this will change soon) the percona and git/gitweb containers were started but not reachable, I couldn’t start them again, restart works but no ports were set, no IP seen in `docker ps`, etc. Then I’ve made `service docker restart` again and the contiatiners were working but I better check the firewall and the system as a whole when changing anything in the containers, also `docker ps -a`, `docker top cont_name` and `docker logs cont_name` and rebooting the whole host server to fix it if not possible either way. I still don’t know a lot of things about system administration, still I think this problem comes from 1-2 containers that have an exotic way of installation/configuration inside. I will definitely check them one by one and probably when docker 1.0 is here I will have fixed my problem as well! 🙂

Update2:

After I changed the process holding the container, using mostly the `tail -f filename.log` command, the logs produced for `docker log containername` are coming more often and after a few days I still have good results for `docker top containername` on the troubled containers which are more than fine now. Probably if there is not a log for a long time the container will show you nothing when executing `docker top` on it. We’ll see.

Let’s be patient and continue testing this great tool!