Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extending installer to use buildah instead of docker build #8969

Open
ghost opened this issue Dec 22, 2020 · 7 comments
Open

Extending installer to use buildah instead of docker build #8969

ghost opened this issue Dec 22, 2020 · 7 comments

Comments

@ghost
Copy link

ghost commented Dec 22, 2020

ISSUE TYPE
  • Feature Idea
SUMMARY

I am trying to build my own custom image on a RHEL machine and that has an ancient version of Docker installed on it which does not support multi stage builds, which is required to build your own AWX Images. So I thought lets use buildah instead.

I did put a bit of effort into building all that is required into the installer of awx and would want to share that. Since there is no buildah module I am using the shell module instead. My two questions are:

  1. Are you interested? --and if the answer to 1 is yes,
  2. How do I contribute it?

See, this is my first time contributing to OpenSource. I did read the contribution guide but am still a bit lost on the part with the git rebase vs. git merge. So I hope you bare with me and help me out on this:

So my understanding was that I would have to:

git clone https://github.com/ansible/awx.git
do my changes
git commit --signoff

And what would be after that?
cheers,
Sebastian

@wenottingham
Copy link
Contributor

That process is mostly correct, but you'd want to do that in a fork on GitHub. See https://opensource.com/article/19/7/create-pull-request-github

I would note that @shanemcd has been doing work on refactoring the image build , so there may be some overlap here.

@shanemcd
Copy link
Member

shanemcd commented Jan 4, 2021

We would welcome a PR to add Buildah support, but this would need to be exposed an a configurable (non-default) option. Most folks don't use Buildah, and it is not as widely available as Docker is.

Perhaps you could detect if Docker is installed, if not, then check for Buildah.

I would also encourage you to consider podman build, as this is more of a drop-in replacement than calling buildah bud

@ghost
Copy link
Author

ghost commented Jan 4, 2021

@wenottingham Thanks a lot! This article looks like the sort of explaination I was searching for :-)

@shanemcd I think you are right. And since I am half way there with buildah anyway, I will simply do both. It's not so much of an extra effort.

So my proposed solution would roughly look like this and your feedback is obviously much appreciated:

Inventory

  1. Add 2 extra Variables, one for the build tool and one for the container runtime

check_vars

  1. Check whether a build tool is set in the inventory. If not, default to docker
  2. Check whether a container runtime is set in the inventory. If not, default to docker
  3. Check if the choosen tools are actually available

image_build

  1. find all tasks that are done with docker
  2. add conditions to these to reflect the dependency on the build or container runtime tool selected
  3. duplicate those tasks and modify for podman
  4. do the same for buildah

image_push

  1. find all tasks that are done with docker
  2. add conditions to these to reflect the dependency on the build or container runtime tool selected
  3. duplicate those tasks and modify for podman
  4. do the same for buildah

local_docker
I haven't really looked at this, so I am not really sure on what it actually does. Is this worthwhile to go for this as well?

@shanemcd
Copy link
Member

shanemcd commented Jan 4, 2021

@it-baschtler In case you didn't see the open PR before it merged this morning, check this out: #8980. It removed a lot of code from the image_build role, and will probably require you to rebase.

Regarding changes to local_docker, this install path will be going away in the not-too-distant future. See this thread for more information: https://groups.google.com/g/awx-project/c/47MjWSUQaOc/m/bCjSDn0eBQAJ

@ghost
Copy link
Author

ghost commented Jan 4, 2021

@shanemcd Thanks for the hint, will do. If the local_docker is going byebye anyways, I will not look at this for the moment.

Will try to get the changes in sometime later this week, depending on how time permits.

@ghost
Copy link
Author

ghost commented Jan 11, 2021

So, I figured there seems to be a little bug in the file awx/installer/roles/kubernetes/templates/postgresql-values.yml.j2

It says line 45 and 46:

repository: postgresql tag: '12.5.0'

should really be:
repository: postgres tag: '12.5'
I would fix this with the podman and buildah thing.

image

@ghost
Copy link
Author

ghost commented Jan 13, 2021

@shanemcd Now I know what you meant with the buildah vs. podman thing. It seems that I had a bit of a missconception here on what buildah run is doing. I am going for podman now and skip buildah alltogether for the moment.
Since you have done a great job with the installer already, and I am on it anyway I do have a bit of a conceptual question.

So the installer is about building first, pushing then and installing after. Now, with that in mind, my question is this:

In the kubernetes role:
This is set in the defaults/main.yml:

kubernetes_awx_image: "ansible/awx"

And this is done in tasks/main.yml:

- name: Set image names if using custom registry
  block:
    - name: Set awx image name
      set_fact:
        kubernetes_awx_image: "{{ docker_registry }}/{{ docker_registry_repository }}/{{ awx_image }}"
      when: kubernetes_awx_image is not defined
  when: docker_registry is defined

Isn't the tasks/main.yml portion kinda unreachable? I think the defaults/main.yml entry should go away. In fact I've tested that locally and seems to work and it seems to not break anything. I would want to put that into my PR together with the podman build and the fix of the postgre template.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants