Fire up an interactive bash Pod within a Kubernetes cluster

In those cases where you need a throw-away interactive shell within your cluster:

$ kubectl run my-shell --rm -i --tty --image ubuntu -- bash

You may, of course, use a different image or shell. Some of the arguments explained:

  • my-shell: This ends up being the name of the Deployment that is created. Your pod name will typically be this plus a unique hash or ID at the end.
  • --rm: Delete any resources we've created once we detach. When you exit out of your session, this cleans up the Deployment and Pod.
  • -i/--tty: The combination of these two are what allows us to attach to an interactive session. 
  • --: Delimits the end of the kubectl run options from the positional arg (bash).
  • bash: Overrides the container's CMD. In this case, we want to launch bash as our container's command.

Note that you'll need to update your apt cache before you can install packages:

$ apt update
$ apt install cowsay

Once you are done with your tinkering:

$ exit

Post-exit, the Deployment and Pod that kubectl created will both be stopped and deleted, taking with it our container and anything we did within it.

Cassandra 2.1 Docker images and lockups

We recently noticed that we had locked up Cassandra Docker containers piling up when running our integration tests.

After digging around some more, we saw some others complaining of similar symptoms. Something in common with all cases was the use of Cassandra 2.1.x images. After seeing someone mention that Cassandra 2.2 and 3.x images weren't showing this behavior, we gave it a shot.

As luck would have it, this did the trick! So for anyone else running into Cassandra Docker containers with the following symptoms, consider switching to 2.2+:

  • Containers never fully start, hanging after creation.
  • Containers can't be rm'd or killed.
  • docker logs shows no output in addition the the previous two.

Using Drone CI to build and push images to Quay.io

As my experimentation with Drone continues, the latest task was to get Docker images building and published to Quay.io (more on why we're using Quay here).

Drone uses a .drone.yml file to determine what happens in response to a `git push` (or other events). We tend to use the build section (not shown below) for running our tests, and the publish section for actually building and publishing the image from a Dockerfile. Read on for an excerpt from a single-page JS app I helped deploy today.

Read More

drone-hipchat released. A HipChat plugin for Drone CI.

Since the Drone CI Plugin Marketplace didn't have one yet, I put together a quick plugin. It's written in Python instead of Go, so it won't ever be in the official plugin namespace, but it also requires substantially less boilerplate than the Go plugins. So we'll run with it because it's simple!

If this interests you, check out the Github repo and the documentation. You should be able to copy/paste that sample YAML and substitute your values. Since all Drone CI plugins are Docker containers, you'll get the benefit of automatic updates if/when I make improvements or fixes in the future.

I'm all ears for feedback, which you are encouraged to send to the issue tracker.