Execute on file change

put entr in your toolkit.

You have all been there – wanting to execute something whenever a file or a set of files changes. There are several tools that will help you, but so far entr is the simplest, most no-nonsense solution I have found.
I’ve been using it the past few days when creating a dynamic nginx reverse proxy config with consul-template, and it works like a charm.
Go check it out – it is available through apt on ubuntu and brew on OSX.

Semantic versioning, git flow and tags

Semantic versioning microutility

I have a lot of minor projects that follows the semantic versioning standard. Coupled with git flow this makes my life a little easier. Life can always get easier though, so here is a very rudimentary script for retrieving next version from the latest tag in git:

#!/usr/bin/env ruby
inc = ARGV[0]
version = `git describe --tag $(git rev-list --tags --max-count=1)`
v = Hash[[:major, :minor, :patch].zip(version.split('.'))]
case inc
  when 'major'
    v[:major] = v[:major].to_i + 1
    v[:minor] = 0
    v[:patch] = 0
  when 'minor'
    v[:minor] = v[:minor].to_i + 1
    v[:patch] = 0
  when 'patch'
    v[:patch] = v[:patch].to_i + 1
end
puts v.values.join('.')

put it somewhere in you path, and call it something like nextver, and the next time you are doing a release, just run

git flow release start $(nextver minor)

No need for checking what the last release was, it is automagically handled:)

Automatic cache invalidation in Dockerfile

Sometimes, you would like docker to not be too smart with regards to the caching done by docker build…

I have a utility image built by my ci server whenever I push updates to a locally developed gem. The ci-system pushes the gem to the local gemserver, but whenever the utility image is built, it believes that it has already performed the step

RUN gem install gem_name

…and I will end up with a utility image containing an old version of the gem. As I do not want to build with the –no-cache option (that would force a full rebuild of the image), and I do not want to rely on manually updating any files ADDed in the Dockerfile, I ended up doing the following:

As part of the build step, my ci server now generates the file invalidate_cache by the following command:

head -n 500 /dev/urandom|md5 > invalidate_cache

…and in my Dockerfile I do a

ADD invalidate_cache /invalidate_cache

just before the gem installation command. As invalidate_cache will always have new content, docker will invalidate all caches after this step, and I get a properly updated image created each time.

ansible, docker and ports

If you are using ansible to deploy docker containers, you might have run into the problem where, despite you exposing ports via the ports: option, the ports are not exposed anyway. You think you have set up your services according to plan, but for some reason, after pulling out your hair because of communication errors, you bring out iptables – and lo and behold – only a subset of the ports reported as exposed by docker inspect are actually exposed.

It turns out that when starting docker images from ansible, only ports exposed directly from the image will actually be exposed. Why, oh why!

Luckily, you do not need to rebuild your images, as you can explicitly expose them from ansible through the expose: section

So there you go – if you have a docker image exposing 80 (via EXPOSE keyword in the Dockerfile), but you want to expose 443 as well through ansible – the following will not work:

ports:
  - "{{ansible_default_ipv4.address}}:80:80"
  - "{{ansible_default_ipv4.address}}:443:443"

…as this will only expose port 80. However, the following will fix things up:

expose: 443
ports:
  - "{{ansible_default_ipv4.address}}:80:80"
  - "{{ansible_default_ipv4.address}}:443:443"

This will expose both ports 80 and 443.

Mission accomplished, and a big %*$% to ansible for not documenting that the ports option does not work like the docker -p option (they are syntactically identical, but thats about it).

Informasjonsaggregering

Dette er noe som har forundret meg lenge. Vi har i dag http/html som håndterer lenking av informasjon, noe som i og for seg er fint, men det er akk så begrensende. Linking er i bunn og grunn informasjonsaggregering, men den går kun èn vei. 
NJS Bicycle Chain
Creative Commons License photo credit: vxla
Vel, at det hele er unidireksjonelt er ikke helt sant – man kan benytte seg av linkbacks, men dette er meg bekjent en one-off ting, som ikke videreføres med beskjed om at lenkingen er terminert, eller at det originale innholdet det pekes til er endret.

Et annet problem med lenkene er at de sender deg ut av konteksten du er i for å innhente informasjonen det pekes til. I mange tilfeller er dette, vel – suboptimalt.

Ønsket mitt er som følger: Jeg ønsker å kunne inkludere deler av informasjon innhentet annenstedsfra direkte i innholdet jeg lager, slik at informasjonen kan leses direkte i kontekst av det innholdet som presenteres. Dette kan selvsagt løses ved å sitere den delen av innholdet som er av interesse, men i dèt øyeblikket man har gjort dette løper man risikoen av divergens mellom innholdet som er sitert, og den faktiske informasjonen som er tilgjengelig. I en verden hvor informasjon er plastisk er det ofte ønskelig at informasjonen som hentes inn skal kunne holdes løpende oppdatert.

La meg gi et eksempel: I en protokoll/brukerhåndbok har man beskrevet forskjellige handlinger en bruker kan utføre. Blandt disse finnes det en del atomiske handlinger (la oss som eksempel bruke: “Logg på systemet”) og sammensatte handlinger som eksisterer som sett av atomiske handlinger og supersett av disse settene igjen. La oss nå si at man har beskrevet fire forskjellige handlinger i dokumentasjonen som inkluderer handlingen “Logg på systemet”. La oss videre si at det i levetiden til systemet blir gjort endringer i det atomiske handlingen “Logg på systemet”.  Hvis man har sitert/kopiert den originale beskrivelsen i de andre handlingene må man nå oppdatere samtlige av disse for at protokollen fremdeles skal gi et bilde av hvordan systemet fungerer. Dette blir fort et lite vedlikeholdsmareritt, for det er ikke en gang selvsagt hvor informasjonen har blitt kopiert til.
Lenker i dette tilfellet vil selvsagt ikke ha samme problem, men i dette tilfellet har vi problemet med kontekstendring (brukeren må følge lenken ut av protokollen og utføre det som er beskrevet i “Logg på systemet” og deretter returnere til den opprinnelige konteksten brukeren forlot).

En mulig løsning på dette problemet ville vært å utvide lenkebegrepet til å fungere som et “vindu” inn til den informasjonen man ønsker å formidle. Altså: i de fire handlingene som inkluderer “Logg på systemet” ville informasjonen bli hentet dynamisk fra den opprinnelige beskrivelsen av handlingen, og dermed ville det kun være nødvendig å endre informasjonen èn plass i systemet.

Dette er dòg ikke nok – det er også interessant for den som endrer informasjon å vite hvor det blir referert til informasjonen som er under endring – om enn ikke av andre grunner enn for å sjekke at informasjonen fremdeles er relevant i de andre kontekstene.

Det er selvsagt en del problemer som må løses innenfor et slikt system:

  • Man må kunne identifisere spesifikke deler av informasjon for at referansene skal kunne håndteres. Dette burde kunne håndteres vha. strukturell metadata
  • Det burde være mulig å endre referansene (monkeypatching). Dette burde være mulig ved å patche direkte ved henting av referansen (hvilket også ville gjøre det mulig for brukeren å se hvilke endringer som er gjort fra originalmaterialet)
  • Linkråte. Kanskje dette problemet kunne minimaliseres ved å kjøre backenden for informasjonsdelingen over et distribuert versjonskontrollsystem (git?) hvor man beholder en lokal kopi av det refererte materialet og kan (velge) å oppdatere ved endringer i det originale materialet.

Kjenner noen av dere til systemer som kan håndtere dette allerede (m.a.o. – er dat bare jeg som har falt av teknologivogna)?