Blog
Run Containers Easily with Podman + Flox
Ross Turk | 25 April 2024
For years, I used containers every single day.
Almost always, it was the same pattern: I would spin up container with a tool or service I need - a CMS, data orchestration platform, time-series database, or old text-based adventure game - then shut it down and try again with at least one volume mounted and at least one port forwarded.
I may not have always needed the isolation that containers provided; in fact, I would work around it a lot of the time. But they were still the easiest way to get the software I needed.
Since I started using Flox, I don't use containers to consume software anymore. But they're still incredibly useful.
When we really do need to run something in isolation, there’s no substitute for the almighty Linux container. It is the perfect balance of isolation and convenience for most cases. And, as it turns out, it’s extremely convenient to run containers using Podman and Flox.
Activating Podman in a Remote Environment
The easiest way to run containers on a machine that doesn’t already have Docker or Podman installed is to activate the flox/podman remote Flox environment.
This Flox environment contains:
- the
podman
package podman-compose
, a Podman alternative for Docker Compose- a hook that verifies configuration and starts the Podman machine
To activate it, Install Flox and run the following command:
The best thing about Podman is that it doesn’t require you to run any services or daemons. You will, however, need a Podman machine if you’re running on macOS. The profile script for this environment will ask you whether you want this Flox environment to be started automatically when you activate the environment in the future:
Once the environment is activated and Podman is ready, you will see the following output:
This means that you can now use the podman
command within this activated shell. To verify that it works we can run the Podman hello
image:
When you no longer need to use Podman, exit the Flox environment by typing ^D
(Ctrl+D) or exit
- it’s as easy as leaving the subshell we created when we ran flox activate
.
All of this was possible without installing a desktop app, or leaving the shell you were already working in. When you no longer need it, and you exit, it’s simply not in your $PATH
anymore.
Seeing how it works
Flox remote environments can be viewed with the flox list
command. You can pass it -c
to see the entire manifest (instead of just a list of packages) along with -r
and a remote environment name.
To see what’s inside this environment, run flox list -cr flox/podman
. You can see the list of packages and the contents of the script that runs when it is activated.
This is just an example. It is easy to create your own Flox environments just like this one. and push them to FloxHub so you can use them everywhere you go.
Creating a Flox project with Podman
Sometimes you need Podman as a permanent part of your project's stack. Perhaps you require multiple copies of a service that attempt to claim the same ports. Or you need to run a set of tests in a way that is guaranteed not to be influenced by outside software or configuration.
With Flox, Podman can be included in a project the same way we would include any other piece of software.
Let’s say we want to start a project where we use Python to store information inside a PostgreSQL database. We can initialize our project using Flox with the flox init
command.
Then, we can install Python, our PosgreSQL client, and Podman inside our new environment using flox install
, and then activate it using flox activate
:
Inside our activated Flox environment, we can start the Podman machine (if on a Mac) and then spin up an instance of PostgreSQL for us to write our data into:
With our database started, we can use Python and the psycopg2
PostgreSQL client to connect to it and do our work:
So, what has Flox left behind? If we look inside our new project directory, we can see that Flox has created a set of files. They are all tidily tucked into the .flox
directory, and they can be used to rebuild this environment in the future.
These files can be checked into a Git repository alongside your project code. The .gitignore
file is there to make sure that you don’t check in the runtime files in .flox/run
, which are symlinks created on each system where you run Flox.
Flox is free to download and use. Next time you (or your project) needs to run a container, give it a try!