A quick post today.
I find myself working with a surprising number of different languages/environments day to day. In the last week, I’ve worked with PHP, Python, Go, Ruby, and Javascript. And different versions of several of those. While I could install something like virtualenv for Python / rbenv for Ruby / etc, I already have a tool exactly designed for this sort of thing: Docker!
DeepDream is a research project originally from Google that gives you a look into how neural networks see the world. They’re fascinating, bizarre, and a lot of fun to play with. A bit of work getting them to work on your own machine though.
Luckily, GitHub user saturnism has put together a lovely Docker-based tool that will do just that for us: deepdream-cli-docker. Unfortunately, the commands are still a bit long. Let’s clean it up a bit and add the ability to dream about non-JPGs (animated GIFs especially!).
From time to time when doing web development, you need to test something related to HTTPS. In some cases, the application you’re writing already supports HTTPS natively and that’s no problem. But more often (and probably better, in my opinion) is the case when you have another service (be it an AWS ELB or an nginx layer) that will terminate the HTTPS connection for you so your application doesn’t have to know how to speak HTTPS.
In those cases, how can you test functionality that specifically interacts with HTTPS?
Today I will show you autohttps, a thin nginx proxy using Docker and a self signed certificate to automatically create an HTTPS proxy in front of your application.
As I’ve mentioned a couple of times recently1 2, I have set a handful of different things on my local machines to make remote development a bit easier. This time around, I have two more to add to that list:
In both cases, I have these running on an always-on server that I use for various projects just like this. It could just as easily be set up to run on a Raspberry Pi or on your local machine.
I was working on a docker container which uses the aws cli to mess around with some autoscaling groups when I got a somewhat strange error:
A client error (SignatureDoesNotMatch) occurred when calling the DescribeAutoScalingGroups operation: Signature not yet current: 20171115T012426Z is still later than 20171115T012420Z (20171115T011920Z + 5 min.)
Hmm.
Are the clocks off?
When developing using docker on OS X, you’ll currently1 have to use docker-machine to spin up a virtual machine that is actually running the docker containers. Running a virtual machine takes up a bit more in the way of resources than just the docker containers, so if you’re not actually developing at the moment, it’s helpful to be able to start up the virtual machine only when you need it.
The current way I have to do that:
$ docker-machine start default
$ eval $(docker-machine env default)
What’s worse, the latter command has to be run for every shell that you start up. It’s by no means a hard pair of commands and you could easily wrap them in an alias or put them in your .profile equivalent (which is what I used to do). But unfortunately, I found a completely unrelated bug in tmuxp: if the shell takes too long to start up, tmuxp essentially won’t work. The above eval command took long enough to hit this limit.
Recently at work, we were trying to get an application that uses websockets working on an AWS instance behind an ELB (load balancer) and nginx on the instance.
If you’re either not using a secure connection or handling the cryptography on the instance (either in nginx or Flask), it works right out of the box. But if you want the ELB to handle TLS termination it doesn’t work nearly as well… Luckily, after a bit of fiddling, I got it working.
Update 2018-05-31: A much easier solution, [https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/](just use an ALB):
WebSocket allows you to set up long-standing TCP connections between your client and your server. This is a more efficient alternative to the old-school method which involved HTTP connections that were held open with a “heartbeat” for very long periods of time. WebSocket is great for mobile devices and can be used to deliver stock quotes, sports scores, and other dynamic data while minimizing power consumption. ALB provides native support for WebSocket via the
ws://andwss://protocols.
I had an interesting problem recently on a project I was working on. It’s a simple Flask-based webapp, designed to be deployed to AWS using Docker. The application worked just fine when I was running it locally, but as soon as I pushed the docker container…
Latency spikes. Bad enough that the application was failing AWS’s healthy host checks, cycling in and out of existence1:
I’ve been using Docker a fair bit at work, so I’ve added a few quick aliases to my dotfiles make that a little bit easier:
docker-bash - attach a bash shell to the first available docker instancedocker-stop-all - stop all running docker instances