(This could easily be an alias instead, but I’m sharing it with the team and want to make things super-simple for everyone.) Here’s an example where I use toolbox, not buildah, to create a working environment (for running Jekyll locally for Cockpit’s website):Īnd then I pair this with a run command too: I started to define my work environments in Dockerfiles, but decided to switch over to writing buildah.Ĭool! I’ve been doing the same, both with Docker and then with Buildah.įor some projects, I now have started to use toolbox in simple scripts (thanks to its run command) to build a container too. So I guess I’m not working to quickly provision containerized work environments, as much as I am setting up the infrastructure to have them pre-built, and instantiated later, as needed… Then when I start to work, I can “throw away” a build environment and just jump into the latest one built and deployed to the registry. That way, whenever I change a config, Jenkings can automatically rebuild the chain of images (I’m trying to layer them), test them (maybe?), and then push the images to a registry. The goal, is ultimately to define build scripts in a repo, and then set it up with Jenkins or some other CI/CD system. I can then simply pull these images down and run them with podman, whenever I want. Using the scripts, I can build container images which define my work environments. It turns out buildah is very powerful and should provide a bunch of flexibility. I started to define my work environments in Dockerfiles, but decided to switch over to writing buildah. I’ve used ansible to provision my host systems in the past.įor the container side, I’m still in the planning/experimenting stages but I think I have an idea of what I plan to do.

My pc cleaner