Articles, notes and random thoughts on Software Development and Technology
When running a ‘docker build . -t imagename’ to build a new image, each of the steps in your Dockerfile outputs a one-line status, but if you need to see the actual output of each step, you need pass the –progress-plain option. If your build is stopping at a particular step and you need to see the output of previous steps that are now cached, you can use the –no-cache option:
docker build --progress=plain --no-cache . -t imagename
In my previous post I walked through a couple of tutorials to deploy a test Docker container to AWS ECS Fargate. As a summary, here’s the various parts that you need to have in place to deploy a Docker container using Fargate:
Turns out if you have an older base image downloaded locally and you try to rebuild your own image based on it a couple of years later, you could get errors running apt-get in your own Dockerfiles. I just got errors like this rebuilding an image that I first created 2 years ago:
Err http://archive.ubuntu.com/ubuntu/ trusty-updates/main libcurl3 amd64 7.35.0-1ubuntu2.14
404 Not Found [IP: 91.189.88.149 80]
Get:16 http://archive.ubuntu.com/ubuntu/ trusty-updates/main ca-certificates all 20170717~14.04.1 [167 kB]
Err http://archive.ubuntu.com/ubuntu/ trusty-updates/main krb5-locales all 1.12+dfsg-2ubuntu5.3
404 Not Found [IP: 91.189.88.149 80]
Get:17 http://archive.ubuntu.com/ubuntu/ trusty/main libsasl2-modules amd64 2.1.25.dfsg1-17build1 [64.3 kB]
Err http://security.ubuntu.com/ubuntu/ trusty-security/main libcurl3 amd64 7.35.0-1ubuntu2.14
404 Not Found [IP: 91.189.88.31 80]
Err http://security.ubuntu.com/ubuntu/ trusty-security/main openssl amd64 1.0.1f-1ubuntu2.23
404 Not Found [IP: 91.189.88.31 80]
Err http://security.ubuntu.com/ubuntu/ trusty-security/main curl amd64 7.35.0-1ubuntu2.14
404 Not Found [IP: 91.189.88.31 80]
Fetched 1375 kB in 7s (175 kB/s)
E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/k/krb5/libkrb5support0_1.12+dfsg-2ubuntu5.3_amd64.deb 404 Not Found [IP: 91.189.88.149 80]
If you delete the base ubuntu image you have cached locally, and try again, you’ll pull down a latest image, and now your build should continue as expected.
This website running this blog has been running in Docker containers on a small-ish 4GB VPS for the past 9 months pretty much issue free. You can follow by journey to migrate this site to Docker in posts here and here.
Since I’ve been spending time recently getting up to speed with Kubernetes, the next logic step would be to deploy to a Kubernetes cluster, which would give me an opportunity to find out what it takes to run Kubernetes. I’ve looked at managed offerings on Google and AWS, but the cost for a few small personal projects is a little more than I want to spend.
I have a 8GB VPS ready to go, so far installed with Docker and Kubernetes running as a single node cluster, and I’m starting to plan my strategy for migrating to this new server. The first thing I’ve been thinking about is whether I should take my existing Docker images and just deploy to Kubernetes as is. Where I’ve got stuck so far is I don’t know enough about how to run NGINX with WordPress and MySQL in multiple pods, so I think I might install the WordPress Chart using Helm and for the time being not worry about how to do this myself.
The next thing I’ve been looking at is how to configure an Ingress to access different deployed services via different urls. I’ve been looking at setting up Traefik as the Ingress Controller to do this, and will be sharing a post about that config shortly. What I’m interested in is being able to deploy a number of different projects, including my WordPress site, and have them accessed via different urls, and it looks like Traefik will handle this fine.
I plan on writing some further posts as I make this transition over the next couple of weeks.