tmate is an awesome tool I use to do work/debug session on someone else terminal. Learn more about tmate here. Sadly their default server is not available anymore, at the time of writing this article you have to setup your own tmate server, I could not find a lot of documentation on internet so here we are!

# ssh into your server (e.g. 51.158.172.10)
# install docker
mkdir tmate && cd tmate

# this command will download the create_keys script and create a "keys" folder in the directory
curl -s -q https://raw.githubusercontent.com/tmate-io/tmate-ssh-server/master/create_keys.sh | bash

# don't forget to setup tmate client on the machine you want and configure ~/.tmate.conf with the information outputed by the previous command

# now let's start the server (don't forget to change "sub.my-domain-name.com") with the domain name pointing to your server
# I choose 2223 but any other port will do

docker run -d --name="tmate-server" \
  --cap-add SYS_ADMIN \
  -v  $(pwd)/keys:/keys \
  -e SSH_KEYS_PATH=/keys \
  -p 2223:2223 \
  -e SSH_PORT_LISTEN=2223 \
  -e SSH_HOSTNAME=sub.my-domain-name.com \
  -e USE_PROXY_PROTOCOL=0 \
  tmate/tmate-ssh-server:prod

Now back on your client machines (e.g. personal laptops, or your friend laptop):

# install tmate client (check https://tmate.io/ for instructions)
nano ~/.tmate.conf

# paste what was printed from create_keys.sh

set -g tmate-server-host "IP_OR_DOMAIN_OF_YOUR_SERVER"
set -g tmate-server-port 2223
set -g tmate-server-rsa-fingerprint SHA256:xxxxxxxxxxxxxxxxxx
set -g tmate-server-ed25519-fingerprint SHA256:xxxxxxxxxxxxxxxxxxxxxx

You now are good to go!

Even if I often saw docker-compose misused...

... I do find it sometimes useful when I develop locally. But I can't bear the cmd+tab + ctrl+c + up + enter each time I want to reload my containers because some configuration file changed. I'm not the only one, an issue exists on docker-compose project since 2014 (Watch code and automatically rebuild when something changes).

So here is a one-liner that works and restart docker-compose each time a *.yml, *.toml or *.conf file change:

watchexec --restart --exts "yml,toml,conf" --watch . "docker-compose up"

I used watchexec (rust) but you could definitely use something else like nodemon (nodejs).

And if you wish to restart docker-compose each time files from a specific folder are updated (e.g. api/), --filter is what you are looking for:

watchexec --restart --filter "$(pwd)/api/*" --watch . "docker-compose up"

For extra sweetness — because who wants to remember this one-liner forever? — I put the function below in my ~/.zshrc

function docker-compose-watch() {
  local args;
  if [[ $1 == "help" ]] || [[ $1 = "--help" ]]; then
    watchexec --help | grep -A 3 "OPTIONS:";
    return;
  else
    args='--filter "*/docker-compose.yml"' && [[ $1 ]] && args=$@;
  fi
  eval watchexec --restart $args -w $(pwd) "docker-compose up"
}

alias docker-compose-reload=docker-compose-watch;

Usage:

docker-compose-watch --help
OPTIONS:
    -e, --exts         Comma-separated list of file extensions to watch (js,css,html)
    -f, --filter ...      Ignore all modifications except those matching the pattern
    -i, --ignore ...      Ignore modifications to paths matching the pattern

docker-compose-watch -e '*.js' -i './api'
Starting api_worker_1
Starting api_postgrest_1
Attaching to api_worker_1, api_postgrest_1
[... updating a file ...]
Gracefully stopping... (press Ctrl+C again to force)
Stopping api_postgrest_1 ... done
Stopping api_worker_1 ... done
Starting api_worker_1
Starting api_postgrest_1

Note: I definitely prefer to restart docker-compose up after each file change (with soft shutdown) than have to first remember to run docker-compose up and then run watchexec ... "docker-compose restart" and finally ctrl+c + docker-compose down.

For Image-Charts, Redsmin and the-to-be-announced-next-SaaS I use Jenkins as the continuous integration system. Lately I discovered that 75% of Image-Charts project build time was related to the dependencies installation part.
I don't like and do not advise to enable caching at the build level because it inherently breaks the principle of repeatable and independent builds thus for every project I work on each build starts with a clean empty cache.

So I wondered how long Image-Charts build would take if we were to replace npm with yarn for the dependencies installation part.

For a medium-sized project like Image-Charts (39 dependencies and 9 dev-dependencies and some native dependencies) switching the installation step to yarn reduced the build time by up to 37% which is really awesome! The next pain point to improve would be a switch from mocha to ava in order to leverage parallel tests execution but that's another story!

I'm currently adding Rust support to MailChecker thus I had to run the Rust generated project tests on CircleCI. At the time of writing, CircleCI does not support Rust and Rustup setup had an issue with CircleCI. I just wanted to find the easiest way to use cargo test in the CI and the good news is: that's what Docker is good at!

Just add a single line to your circle.yml file and you are good to go, I hope this will help others!

Running a jenkins slave inside docker is more often than not good enough, you may want to run jenkins jobs that requires docker cli. I just release a docker image that does just that.

• Go to Jenkins > manage > node management
• Click Create a node
• Check Permanent Agent
• Set working directory to something like /data/jenkins-slave (if you specify something else, don't forget to also change the command below)
• Save
• Download slave-agent.jnlp, open it to retrieve your secret
• Change the command below with the working directory you specified, your slave-agent URL and jenkins secret

docker run --rm \
-v /data/jenkins-slave:/data/jenkins-slave \
-v /var/run/docker.sock:/var/run/docker.sock \ 
--rm fgribreau/jenkins-slave:latest java -jar /app/agent.jar \ 
-jnlpUrl "http://YOUR_OWN_JENKINS.com/computer/SLAVE_NAME/slave-agent.jnlp" \
-secret "JENKINS_SECRET"

• Run it
• Done 👍

Why is this awesome?

Now that I can use docker directly from Jenkins jobs, it means I can setup cron jobs through jenkins just with configuration. Since one of docker sweet point is the ability to run CLI tools without any more setup that downloading an image, I now can setup nightly elastic/curator cron jobs just from Jenkins interface without the initial overhead of environnement setup.

I get fail build notifications directly from Hipchat (always be proactively alerted when something goes wrong!), traceability (who started the job) and of course I can reuse my Jenkins authorization setup for cron job as well. Thus no need to setup something like Rundeck when Jenkins already handles the feature set I want!

I had to handle a 2 month old issue related to ElasticSearch. A feature I did not know from one of our large monolithic application at iAdvize was not working anymore. Instead of looking directly at thousand lines of code, the fastest way to resolve it was to gather informations related to the issue from outside the app. I had to answer this questions:

• Is the ElasticSearch server remotely accessible from the frontend servers?
• If it does not, the first thing to do is to bring back the connexion between the two.
• Is the ElasticSearch request valid? 
• If it does not, maybe:
• we are doing the request on the wrong indice/alias? 
• the query body is malformed?
• Does it yield results?
• If it does not
• but we should get some, then either the query is invalid or elasticsearch have an issue
• If it does
• but from the app point of view we don't get anything
• it's related to the app itself and we will have to look at the code

To verify the first 3 points in one shot, I started tcpdump on the ElasticSearch server using the command below:

tcpdump -A -nn -s 0 'tcp dst port 9200 and (((ip[2:2] - ((ip[0]&0xf)<<2 -="" tcp="" xf0="">>2)) != 0)' -i eth1

Note: don't forget to change the interface you want to listen on.

Looking at the result I discovered that the app was doing an elasticsearch query on a missing alias. That explains it! Once the alias created, the application feature was working again in production.

The final step was to setup jenkins (or rundeck) to run daily elastic/curator in order to refresh the alias otherwise :

docker run -it --rm bobrik/curator:3.5.1 --host "elasticsearch.domain.com" --port 80 alias --name plugin-xxx-log indices --prefix plugin-xxx-log- --prefix plugin-salesforce-log- --timestring %Y.%m --time-unit months

Now we will be proactively alerted if anything goes wrong. One less thing to worry about!

[Update] I now also use tcpflow to better display content (too bad it's not maintained anymore):

tcpdump -A -l -nn -s 0 'tcp port 9200' -i eth0 | tcpflow -c -e

First thing first: open Jenkins, go to Settings > Build Nodes > Add new node > Select Permanent Agent, then set the distant workspace directory (our HOST_JENKINS_SLAVE_HOME in the script above) and select Launch agent via Java Web Start.

Finally, login into your slave machine, put and edit the script above, run it and job done!

#!/usr/bin/env bash
JENKINS_ENDPOINT="http://my-jenkins.com"
SLAVE_SECRET="YOUR_SLAVE_SECRET_FROM_JENKINS_NODE_SETTINGS"

# where your slave working dir will be, it should be the same as the one you configured in Jenkins master settings
HOST_JENKINS_SLAVE_HOME="/data/jenkins-slave"

# download the slave.jar on the slave machine
curl -s "${JENKINS_ENDPOINT}/jnlpJars/slave.jar" > slave.jar

# run the slave inside a docker
# replace "-d" by "-it --rm" for debugging
docker run -d --name jenkins-slave -v ${PWD}:/app -v ${HOST_JENKINS_SLAVE_HOME}:${HOST_JENKINS_SLAVE_HOME} java:7 java -jar /app/slave.jar -jnlpUrl "${JENKINS_ENDPOINT}/computer/docker-slave/slave-agent.jnlp" -secret $SLAVE_SECRET