Packaging interactive Python applications?

[kastl-ars]

Dear all,

all of the Python examples I found were "server-like" applications, i.e. running a process and waiting for requests. Think Flask, Gunicorn and the like.

I wanted to try out Buildpacks to package some Python applications that are CLI tools. One example would be the Ansible Builder.

A Dockerfile for an ansible-builder image would look like this.

I tried getting this to work with Buildpacks, but the resulting image set python as the default entrypoint. AFAIK I could define a separate "process" using a Procfile and use the --default-process argument to set this process as the default.

But inside the container I found no trace that the ansible-builder was "installed" at all.

Is there any documentation on how to package interactive applications properly?

Kind Regards,
Johannes

[lMysticl]

The missing installation is expected from the current repository layout: Buildpacks do not execute the RUN instruction in the Dockerfile. The linked repository contains only a Dockerfile and project metadata, with no Python dependency manifest, so the Python buildpack provides CPython and its default python process but has nothing telling it to install ansible-builder.

For a Python-installed CLI, express both the dependency and the launch process as Buildpacks inputs:

# requirements.txt
ansible-builder==3.1.1

# Procfile
ansible-builder: ansible-builder

Then build it with, for example:

pack build ansible-builder-cnb \
  --builder paketobuildpacks/builder-jammy-base \
  --buildpack paketo-buildpacks/python \
  --default-process ansible-builder

With that default process, arguments after the image name are passed to the CLI, for example docker run --rm ansible-builder-cnb --help.

There is one separate concern: ansible-builder build needs access to a container engine. Installing the Python CLI does not put Docker or Podman inside the resulting image. If the goal depends specifically on the openSUSE package or an embedded container engine, keeping the Dockerfile (or writing a custom buildpack/builder) is the more accurate model.

References: the current source repository, Paketo's Python dependency detection, Procfile configuration, and the CNB default-process documentation.

[kastl-ars]

Thanks for the detailled answer, unfortunately I seem to have been unclear in my question.

I forgot to add the link to the actual source repository for ansible builder:
https://github.com/ansible/ansible-builder/

This is what I used in my tests, the Dockerfile link I gave was just to get an idea of how the resulting image should look like.

Thanks for the hint regarding ansible-builder build, I left that detail out as my OP was already long enough. The current image is only being used for the ansible-builder create, anyway.

I cannot add a Procfile, as I am just using the upstream repository. If I understood you correctly, you propose to have a separate repo with the requirements.txt and Procfile and using them to build the image? I'll give this a try!

[kastl-ars]

OK, having a simple repository with the requirements.txt and Procfile files and using this for building works like a charm.

One additional question: Using the Procfile, can I specify ENTRYPOINT and CMD like in a Dockerfile somehow? So the ENTRYPOINT is always used, but CMD is only used if there are no additional arguments in the container start command?

podman container run --rm localhost/my/image runs the container with both ENTRYPOINT and CMD.

podman container run --rm localhost/my/image --some --arguments runs the container with the ENTRYPOINT, but uses --some --arguments instead of the CMD.

[lMysticl]

Not as separate ENTRYPOINT and CMD fields in a Procfile. A CNB image keeps the Buildpacks launcher as its entrypoint, while a Procfile only defines <type>: <command>.

For the same runtime behavior, the small configuration repository can contain a wrapper:

#!/bin/sh
if [ "$#" -eq 0 ]; then
  set -- --help
fi
exec ansible-builder "$@"

# Procfile
ansible-builder: ./entrypoint.sh

Commit entrypoint.sh as executable (chmod +x entrypoint.sh). Then:

• podman container run --rm localhost/my/image runs ansible-builder --help
• podman container run --rm localhost/my/image create ... runs ansible-builder create ...

If create should be the default instead, change set -- --help to set -- create.

CNB process definitions do support a fixed command plus overridable default arguments, but the Procfile schema does not expose those as separate fields; defining them directly would require a small custom buildpack. The launcher behavior is documented in Run the app.

[kastl-ars]

Thanks for the fast reply. Not having ENTRYPOINT and CMD is unfortunate, but thanks for the workaround.