custom version support with ansible-container build & push

[chrisLeeTW]

ISSUE TYPE

• Feature Idea

SUMMARY

When building container & pushing to registry, ansible-container will using date+timestamp as default tag for image.

But a lot of company will use custom version design due to CI/CD build flow.

I know I can use ansible-container push with --tags to workaround.

But aws ECR limits the number of images to 1,000 with one repository, and I only got half quota for the limit with ansible-container.

So it would be awesome to do so.

[chouseknecht]

@chrisLeeTW

I've been thinking about this as well. Thanks for opening this issue. Every time I build an updated version of my Django container, I get a new image, when what I really want is to replace the previous iteration. I don't really care about each intermediate build.

In Docker Compose you can provide both build and image directives. The image produced by the build gets tagged with the value of image.

In Ansible Container we require afrom directive, which provides the base image from which to start the service, and an optional roles directive to specify the list of Ansible roles to apply on top of it.

As you point out, we don't provide a mechanism for allowing the user to set the name and tag values of a built image. Instead, we construct a name by combining the project name and the service name, and tag it with a timestamp.

I'm sure this will break things, but having the flexibility to provide a custom name:tag seems worth the trouble.

I think what's really needed is to provide an image directive that functions similar that of Docker Compose, and a build directive that provides all the build options. An example service constructed in this fashion would look like the following:

services:
   django:
      image: 'app-django:{{ app_release}}'
      build:
        from: 'centos:7'
        roles:
        - role: django
      expose:
      - 8000
      volumes:
      - ${pwd}:/django
      command: ['/usr/bin/dumb-init', '/usr/bin/gunicorn', ...]
      dev_overrides:
        publish:
        - 8000:8000
       command: ['/usr/bin/dubm-init', 'python', '/django/app/manage.py', 'runserver', ...]

In the above example, build brings together the from directive, telling us the base image from which to start the build, and roles, which provides the list of Ansible roles we want to add on top. By doing that, we make it obvious that from is a build directive, and we allow room for an image directive.

The image directive then matches the functionality, I think, of the original Docker Compose image directive. Within the context of run It provides the name:tag of the image from which to run the service. Within the context of build, the value of image will be the final name:tag of the built image.

That's my proposal. It may completely break the build process and our build cach, so we'll need to investigate and do some testing. It's probably not a small effort.

Curious to hear your comments. Does this solve the issue you're experiencing?

[chrisLeeTW]

@chouseknecht Thanks for your proposal.

This is definitely slove my issue. Although this proposal really break the current build process.

After read your proposal, maybe we can just provide the custom image name / tag feature, and default value is still with the previous construct behaviors. (tag is timestamp, and name is combining the project name and the service name)

So we can minimize the impact of current build process ?

[Oloremo]

This feature is really needed