Since its inception, I’ve been serving this website from a single DigitalOcean droplet in the San Francisco region. This approach has served me well and has provided a good simple solution to run this site as well as my personal Nextcloud instance and any other services I wish to experiment with. However, recently I’ve been reviewing how I can modernize this relatively simple static site for better performance and security. Serving out of a single virtual server is quite sub-optimal for some obvious reasons:
The below is a slightly edited version of advice I used to give at Facebook to engineers I was mentoring, hopefully it is useful to the wider world as well. My current mentorship model is quite a bit more complex than this, I plan to post about that in the future. You’re an engineer, you’ve been here a little while. You’ve done a ton of tasks and learned a bunch about engineering and our technology.
Over the last few weeks I’ve put together a pull request for Packer which should be releasing soon with version 0.5.2. With my usage of Packer and Docker, I’ve always found it an annoyance to have to import the Packer built Docker image separately, using Docker import, rather than have Packer handle importing with a post-processor. Once 0.5.2 releases, the deployment of a Packer built Docker image can be optimized through the use of the docker-push and docker-import post processors, through a build template with post-processors much like the following:
WARNING: The openSUSE base image used here is no longer available due to SUSE Studio being deprecated in favor of the Open Build Service (https://openbuildservice.org/2017/09/27/suse-studio-express/). Much of the content here should still be decently accurate however, so I am keeping this post as an archive and reference. When Dockerfiles Aren’t Enough Dockerfiles are a limited solution to a complex problem: the provisioning of Docker images. Dockerfiles at their core operate much like a simple shell script, being a list of instructions to get from a certain state, or base image, to that of a final state, or output image.
WARNING: Much of the content here no long exists or is no longer relevant. Of most pressing note is that the SUSE Studio service has been merged with the Open Build Service (https://openbuildservice.org/2017/09/27/suse-studio-express/) changing much of the instructions about building the JeOS images referenced here. I have also deleted the referenced Docker images and Github repositories in this post since they are no longer being maintained. If interested, I can make an updated version of this post using more modern tools.