docker

Today, I learned the hard way that the default port for ASP.NET Core 8 container images has been updated from port 80 to 8080, quite a remarkable breaking change. We upgraded our web application from .NET 7 and let the CI pipeline do its work. Finally, we checked the application in the browser to ensure everything was okay, but unfortunately, we got a 502 Bad Gateway error. The Nginx logs revealed that the app was rejecting connections, which was unexpected because we didn’t make any changes there....

Another day, another unexpected problem. Launching a .NET 8 app from a docker container, I got this error: Failed to create CoreCLR, HRESULT: 0x80070008. I was puzzled as the same container ran smoothly in our test environment but not in production. I ruled out resource problems (memory or disk full, maybe?) but then compared the Docker Engine versions we run in test and production. Both were old (20. xx when 25 is available), but interestingly, the production version was older....

I added a new tool to my amateurish DevOps toolbox. Developed in the open by Tom Williams, the Docker Event Monitor is a “tiny container that monitors the local Docker event system in real-time and sends notifications to various integrations for event types that match the configuration. For example, you can trigger an alert when a container is stopped, killed, runs out of memory or health status change.” At its core sits a simple python script that monitors the docker....

We want our test and production stacks to be automatically updated every time something new is pushed to the test or release branch. CI builds the docker image on successful test runs, then stores it in our private registry. But how do you automatically pull and deploy those updated images? I looked into the Watchtower project, which is interesting. You add Watchtower to the stack, and it will diligently check for new versions of the images used by the containers in the stack, pulling, building and deploying as needed while the stack is up and running....