Development Containers represent a paradigm shift in software development methodology, encapsulating comprehensive development environments within containerized configurations. This approach addresses the imperative need for consistency across diverse development environments by packaging essential tools, libraries, and configurations within self-contained units. Developers can utilize DevContainers to seamlessly share and replicate their development setups, fostering collaboration and enabling a hassle-free onboarding process for new team members. This enhances efficiency, reduces setup time, and mitigates compatibility issues, ultimately streamlining the development workflow.
The DevContainers CLI is a robust command-line interface integral to managing and manipulating development containers. However, nothing is bug-free, and this post details a troubleshooting experience with the DevContainers CLI to build development multi-architecture development container images with embedded features.
Quite often, one of the most time-taking parts of the build process is the installation of dependencies. This process is traditionally slow because package managers choose stability over performance. And this perfectly makes sense: if something terrible happens, the system must remain in a usable state.
However, stability is not very important when building an image: if the build fails, the system discards the image, and you have to start over.
This post provides some tips on how to use eatmydata to speed up some operations by the example of Debian-based images.
Lando is a local development environment and DevOps tool built on Docker container technology, aimed at providing an easy way for developers to specify requirements for their projects. It provides installation packages for various operating systems, including Ubuntu. However, if you are not using the official Docker distribution, Lando will likely fail to install.
In this article, we describe two workarounds on how to install Lando on Ubuntu.
Multi-stage builds are a great way to keep the size of the resulting image down. They are extremely useful if you want to use scratch-based images for your application. However, unless you are using Buildx or BuildKit, there is a limitation regarding copying extended file attributes across stages. In this post, we discuss several workarounds to this issue.
When experimenting with Docker Swarm, I decided to set up five more nodes on my local computer. I used Alpine images in the LXC, and tried to use Docker in them. Although docker stared successfully, it was impossible to deploy any services to Alpine nodes, deployment failed with “cgroups: cannot find cgroup mount destination: unknown” error message.
Because I dislike when something that should work, does not work the way I expect it to work, I decided to dig deeper and try to fix the problem.