Building a Container

For the past couple of weeks, I have been honing skills in other areas of software development. With all new-ish adventures, there will be learning, with a high probability of banging one's head on the desk. The following is a story of the latter.

My goal for the year with this blog is to reduce the friction of contributing. So far, many changes to the codebase have been committed and pushed to contribute to this year's goal. One thought I have had is to begin using a headless CMS for content management, targeting an API-based CMS technology and removing today's Git-based flow. There are several of these technologies out there. Some are SaaS products, others self-hosted, then select platforms have both as an option. I chose a CMS that supports both hosting options and is fully open source.

With the selected technology, the next decision was how to host it. I opted to host the platform in a Docker container. Since I have experience with content management systems, there needs to be more learning there. I have a little experience creating defining containers, then hosting in my chosen provider. I knew that was a great place to start. The CMS platform had some documentation on containerizing, but it was not officially supported, leaving the door to learning wide open.

The CMS was quick to get started using an in-memory database. Two npm commands and the sample project were functional. Using the pre-defined Dockerfile, building the container was no issue. Executing the same commands as the container on my local, and everything worked as expected. The execution of the container was failing at startup. In the week of troubleshooting this issue, I discovered a dependency the CMS has that is not platform agnostic. I wanted to understand this dependency and what I could do about it. Officially I have six versions of this container. Each with different permutations of a Dockerfile. Some variants include; different node versions, various Linux distribution base images, yarn build tools, and many more. Nothing was working. The error on startup continued.

Finally, I had an idea that led me to a good place. I was considering scrapping the CMS for one that I have official container support. What if I updated the Dockerfile to list the contents of the build directory before taking any actions to build the container image? Immediately, the output had a folder that did not make sense to me. The folder? node_modules. I thought, What is this doing in the build process?. Later in the container build, npm install is issued to fetch the dependencies. I deleted the folder and issued the command to build the container again. No issues in the building with this or any other container. Attempted to run the container. BOOM! It started just as expected. With this new information, I learned about the .dockerignore file and its importance in separating local development from container development.