Choosing timeout values for external service calls isn’t easy. There’s usually black magic involved and sometimes we’re just guessing. This post details the approach we used at Bluestem to choose better values and make our systems more resilient to performance issues and outages in our backend services.

Bluestem has transitioned…

(RIP Prince) If you’ve been following along on GitHub you may know that DockerUI is no longer DockerUI, it’s currently ‘not-dockers-ui’ until I can come up with a better name, and I’ve taken over as the owner of the repo from Michael Crosby.

Why? Three weeks ago two security vulnerabilities were disclosed for the project (that are now fixed) and it became clear that some people thought this was an official Docker project. To clear up the confusion and comply with Docker’s official brand guidelines I will rename the project. You can join the discussion here.

It’s not going away, I’m not going away. Once we pick a name I’ll get automated builds set up on the hub again.

I started using Docker about two years ago and in that time I’ve tried a lot of different things, these are some of the ones that weren’t very good ideas:

Our main web app has a different configuration for each brand (3 but soon to be 16) and we have…

DockerUI is a web GUI for the Docker remote API. It’s like a swiss army knife: very flexible but can be unwieldy to use. Luckily it’s an Angular app that can be modified pretty easily. I want to share what we’ve done at Bluestem to streamline our development workflow. …

If your containers work just fine when started through the CLI but exit immediately when started through the remote API, this may be for you. A common Dockerfile pattern for keeping service containers running is to start the services and then start something that waits for input on stdin, like bash:

CMD /bin/ && /bin/bash

This works for the CLI, but if you don’t explicitly open stdin with the remote API then bash will exit immediately and the container will stop. To open stdin, include the OpenStdin parameter in your container creation call:

POST /containers/create
"OpenStdin": true

Full docs

This is an example of using the remote API to create and run a container with port bindings. This is the equivalent action through the docker CLI:

$ docker run -p host_ip:host_port:container_port image_name

The CLI’s run command corresponds to multiple remote API commands. When using the remote API you need to specify ExposedPorts when creating the container and PortBindings when starting it. (see here for more details)

Specifying ExposedPorts when creating containers:

POST /containers/create
"Image": image_id,
"ExposedPorts": {
"container_port/tcp": {}

Specifying PortBindings when starting containers:

POST /containers/(id)/start
"id": id,
"PortBindings": {
"container_port/tcp": [
"HostIp": "host_ip", // Strings, not numbers here
"HostPort": "host_port"

Kevan Ahlquist

Senior Software Development Engineer @ Amazon. Trumpet player, drum corps enthusiast.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store