This is part of a series on moving from desktop Linux back to Windows.
Note: This post assumes familiarity with Docker and a working Docker for Windows environment (perhaps from reading the previous post), and at least a basic understanding of what Kubernetes is. It does not assume any experience with Kubernetes.
Recently, Docker announced that Docker for Windows has started bundling an integrated Kubernetes, so that we can more easily experiment locally with deploying to Kubernetes in a similar manner as we might deploy to a proper Kubernetes environment.
In this post, I’m going to begin with the end in mind and start with the short answers to my initial confusion for running docker-compose apps on local Kubernetes.
Then, I’ll go into that confusion in a bit more detail, just in case people struggle like I did and perhaps google searches will lead them here.
Keys to running docker-compose apps on local Kubernetes
The docker-compose “getting started” example
I mentioned in my previous post on Docker and docker-compose that I used the basic python app from the docker-compose “Getting Started” documentation as my first stab at compose.
The keys to getting this successfully deployed to local Kubernetes were in modifying
docker-compose.yml like so:
- change the
versionto at least
- add an
imageline for the “web” service, giving it any name you want (doesn’t matter)
docker-compose buildbefore deploying to Kubernetes.
The working version of
docker-compose.yml looked like this:
The following 3 commands built the image, deployed to Kubernetes, and confirmed running in Kubernetes:
docker stack deploy --compose-file .\docker-compose.yml web
kubectl get services
All told, it looked like this when working successfully:
The Docker for Windows / Kubernetes documentation example app
In addition, I could not successfully get the “example app” from the Docker for Windows / Kubernetes documentation running. Initially, this was because the docker-compose file referenced in that documentation was never meant to be standalone, but the documentation doesn’t mention that or point to the actual code that accompanies it. Once I found that, it still failed, and the answer to that problem was fixed in a pull request on the repo. So let’s get that working:
First, here’s the sample app that’s supposed to accompany that documentation. I git cloned that locally and then followed the steps in the README, namely
docker-compose build and
docker stack deploy ..., just like above. This took quite a while because, being maven, it needed to download half the internet.
And then… fail, with something like:
Fortunately, an issue had been filed, with a fix, against the repo, and it was easy to apply. As described in the PR, changing
words/Dockerfile to pin alpine, i.e. changing it from
FROM alpine:3.7, fixed it. After successfully
docker-compose build, it worked as described and the app was available at http://localhost:8080
My initial confusion with a basic docker-compose app
As mentioned above, I want to document the initial errors that I hit when trying to deploy that “getting started” docker-compose app onto local Kubernetes.
But first: Kubernetes aside, following along with the “getting started” example initially, running it with
docker-compose up worked fine. I then added the
volumes line so that I could get F5/refresh when working on the code, and that worked fine too. Thus, when finished, the
docker-compose.yml file looked like this:
And that’s the file I started with when trying to deploy to local Kubernetes.
Here’s the first error I got:
It was, to me, inscrutable. This error:
parse error: services.web.volumes.0 must be a string made no sense to me.
On a whim, I commented out the
volumes bits, re-deployed, and got this new nearly identical error:
parse error: services.web.ports.0 must be a string or number was also not helpful.
At this point, I was pretty well stuck. I don’t recall exactly how I arrived here, but somehow — perhaps by looking at different docker-compose files on the web? — I noticed that my docker-compose.yml had a version of 3, and others had 3.x. So I tried changing to:
version: '3.3'. Success… kind of. I didn’t get errors, but I didn’t have a running web container, either:
Now we’re getting somewhere. But notice that there’s only that
redis service running, and I knew I needed a
web-published service listening on port 5000.