Monthly notes 24

Rain, cold winds and darkness have arrived to Finland and there’s so many good reason to stay at home with warm mug of coffee and read. This month’s notes cover how you should optimize images, how your eyes are telling lies and how to circumvent it in design. You also get pointers to security tools for Docker and running Java apps with Docker and Kubernetes. And if you haven’t migrated to HTTPS check out Troy Hunt’s happy path. Happy reading.

Issue 24, 28.11.2017

User Interface

Essential Image Optimization (ebook)a
Image optimization should be automated. It’s easy to forget, best practices change, and content that doesn’t go through a build pipeline can easily slip. Addy Osmani’s eBook has the essential information you need to get started.

Optical Effects in User Interfaces (for True Nerds)
Making optically balanced icons, correct shapes alignment, and perfect corner rounding when your eyes are telling lies. Interesting article of optical effects in User Interfaces.


Essential (and free) security tools for Docker
Docker makes it easy for developers to package up and push out application changes, and spin up run-time environments on their own. But this also means that they can make simple but dangerous mistakes that will leave the system unsafe without anyone noticing until it is too late. Fortunately, there are some good tools that can catch many of these problems early, as part of your build pipelines and run-time configuration checks. Jim Bird has put together a short list of the essential open source tools that are available today to help you secure your Docker environment.

Deploying Java Applications with Docker and Kubernetes
A good intro to using Docker and Kubernetes for a typical Spring web application. (from Java Weekly 199)


The 6-Step “Happy Path” to HTTPS
HTTPS is now somewhat of a necessity and the path to it can be difficult but it can also be fundamentally simple. Troy Hunt details the 6-step “Happy Path”, that is the fastest, easiest way you can get HTTPS up and running right.

Fast By Default: Modern Loading Best Practices (Chrome Dev Summit 2017)
Optimizing sites to load instantly on mobile is far from trivial. Costly JavaScript can take seconds to process, we often aren’t sensitive to users data-plans, and browsers don’t know what UX-critical resources should load first. One interesting talk is Queryable Real User Monitoring for the web? which tells us about Chrome User Expericence Report Dataset of real world performance as experienced by Chrome users to which you can do SQL queries.

Introducing Code Smells into Code
Code smells are hints that show you potential problems in your code. Martin Fowler describes 21 code smells and Adrian Bolboaca came up with the Brutal Refactoring Coding Game. In the game participants are asked to write the cleanest code possible. If the facilitator spots any code smell, participants must stop and immediately remove it. The post is not about the game but about code smells introduced into code. The game allows observation how and when code smells are introduced (because the whole point is to spot and remove them). (from Java Weekly 199)


Becoming an accidental architect
“How does one transition from developer to accidental architect? It doesn’t happen overnight.” The article describes the journey from developer to architect and how software architects can balance technical proficiencies with an appropriate mastery of communication.

Something different

Pole Bicycles Announces New CNC-Machined ‘Machine’
Finnish bike company Pole has always stamped it’s own path and redefined how mountain bikes can be long and fast. Now they redefined how a frame is made and announced robotically CNC machined frame which is also 100% made in Finland. “The Machine is a cutting edge 29″ superbike which can be used as the one bike for everything. The travel on the bike is 180mm front and 160mm rear. The frame geometry follows Pole’s notoriously long and slack geometry with steep seat tube for better climbing. On our tests, the Machine was even easier to ride than the EVOLINK’s.”

Dockerizing all the things: Running Ansible inside Docker container

Automating things in software development is more than useful and using Ansible is one way to automate software provisioning, configuration management, and application deployment. Normally you would install Ansible to your control node just like any other application but an alternate strategy is to deploy Ansible inside a standalone Docker image. But why would you do that? This approach has benefits to i.a. operational processes.

Although Ansible does not require installation of any agents within managed nodes, the environment where Ansible is installed is not so simple to setup. In control node it requires specific Python libraries and their system dependencies. So instead of using package manager to install Ansible and it’s dependencies we just pull a Docker image.

By creating an Ansible Docker image you get the Ansible version you want and isolate all of the required dependencies from the host machine which potentially might break things in other areas. And to keep things small and clean your image uses Alpine Linux.

The Dockerfile is:

FROM alpine:3.7
  bash \
  curl \
  tar \
  openssh-client \
  sshpass \
  git \
  python \
  py-boto \
  py-dateutil \
  py-httplib2 \
  py-jinja2 \
  py-paramiko \
  py-pip \
  py-yaml \
# If installing ansible@testing
#RUN \
#	echo "@testing" >> #/etc/apk/repositories
RUN set -x && \
    echo "==> Adding build-dependencies..."  && \
    apk --update add --virtual build-dependencies \
      gcc \
      musl-dev \
      libffi-dev \
      openssl-dev \
      python-dev && \
    echo "==> Upgrading apk and system..."  && \
    apk update && apk upgrade && \
    echo "==> Adding Python runtime..."  && \
    apk add --no-cache ${BUILD_PACKAGES} && \
    pip install --upgrade pip && \
    pip install python-keyczar docker-py && \
    echo "==> Installing Ansible..."  && \
    pip install ansible==${ANSIBLE_VERSION} && \
    echo "==> Cleaning up..."  && \
    apk del build-dependencies && \
    rm -rf /var/cache/apk/* && \
    echo "==> Adding hosts for convenience..."  && \
    mkdir -p /etc/ansible /ansible && \
    echo "[local]" >> /etc/ansible/hosts && \
    echo "localhost" >> /etc/ansible/hosts
ENV ANSIBLE_ROLES_PATH /ansible/playbooks/roles
ENV PYTHONPATH /ansible/lib
ENV PATH /ansible/bin:$PATH
ENV ANSIBLE_LIBRARY /ansible/library
WORKDIR /ansible/playbooks
ENTRYPOINT ["ansible-playbook"]

The Dockerfile declares an entrypoint enabling the running container to function as a self-contained executable, working as a proxy to the ansible-playbook command.

Build the image as:

docker build -t walokra/ansible-playbook .

You can test the ansible-playbook running inside the container, e.g.:

docker run --rm -it -v $(pwd):/ansible/playbooks \
    walokra/ansible-playbook --version

The command for running e.g. site.yml playbook with ansible-playbook from inside the container:

docker run --rm -it -v $(pwd):/ansible/playbooks \
    walokra/ansible-playbook site.yml

If Ansible is interacting with external machines, you’ll need to mount an SSH key pair for the duration of the play:

docker run --rm -it \
    -v ~/.ssh/id_rsa:/root/.ssh/id_rsa \
    -v ~/.ssh/ \
    -v $(pwd):/ansible/playbooks \
    walokra/ansible-playbook site.yml

To make things easier you can use shell script named ansible_helper that wraps a Docker image containing Ansible:

#!/usr/bin/env bash
docker run --rm -it \
  -v ~/.ssh/id_rsa:/root/.ssh/id_rsa \
  -v ~/.ssh/ \
  -v $(pwd):/ansible_playbooks \
  -v /var/log/ansible/ansible.log \
  walokra/ansible-playbook "$@"

Point the above script to any inventory file so that you can execute any Ansible command on any host, e.g.

./ansible_helper play playbooks/deploy.yml -i inventory/dev -e 'some_var=some_value'

Now we have dockerized Ansible, isolated it’s dependencies and are not restricted to some old version which we get from Linux distribution’s package manager. Crafty, isn’t it? Check the docker-ansible-playbook repository for more information and examples with Ansible Vault.

This blog post and Dockerfile borrows from Misiowiec’s post Running Ansible Inside Docker and his earlier work. If you want to test playbooks it’s work checking out his ansible_playbook repository. Since then Alpine Linux has evolved and things could be cleaned a bit more like getting Ansible directly from testing repository.