Project

Profile

Help

Story #5657

Story #5132: [Epic] As a user, I can consume Pulp 3 from OperatorHub.io

pulp-operator should deploy nginx as the Pulp Webserver

Added by mdepaulo@redhat.com about 2 years ago. Updated 9 months ago.

Status:
MODIFIED
Priority:
Normal
Assignee:
-
Category:
Operator - Moved to Github Issues
Sprint/Milestone:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

It needs to include:

  1. Pulp Plugin snippets
  2. AutomationHub WebUI (needs confirmation that it gets installed on the Pulp webserver)

Hopefully we can use the generic nginx container, a year ago it would not support the logic in our plugin snippets though.


Related issues

Related to Pulp - Task #6057: [EPIC] Introduce custom plugin snippets for custom apache and nginx routesCLOSED - CURRENTRELEASE

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

Associated revisions

Revision 1ecf4cf6 View on GitHub
Added by chambridge 9 months ago

Add deployment of nginx webserver with pulp snippets

  • Build pulpweb container.

fixes #5657 https://pulp.plan.io/issues/5657

History

#1 Updated by fao89 almost 2 years ago

  • Tags CI/CD added

#2 Updated by mdepaulo@redhat.com almost 2 years ago

I started implementing this: https://github.com/pulp/pulp-operator/pull/26

But stopped due to time, and needing to focus more narrowly on setting content_origin: https://github.com/pulp/pulp-operator/pull/27

#3 Updated by mdepaulo@redhat.com almost 2 years ago

  • Related to Task #6057: [EPIC] Introduce custom plugin snippets for custom apache and nginx routes added

#4 Updated by fao89 over 1 year ago

  • Category set to Operator - Moved to Github Issues

#5 Updated by mdepaulo@redhat.com 10 months ago

  • Assignee deleted (mdepaulo@redhat.com)

#6 Updated by mdepaulo@redhat.com 10 months ago

  • Tags deleted (CI/CD)

#7 Updated by mdepaulo@redhat.com 10 months ago

  • Subject changed from pulp-operator should use nginx and possibly other K8s ingresses to pulp-operator should deploy nginx as the Pulp Webserver
  • Description updated (diff)

#8 Updated by mdepaulo@redhat.com 10 months ago

  • Description updated (diff)

#9 Updated by chambridge 10 months ago

My thinking around this story is that we would deploy an nginx with a mounted configmap volume. https://kubernetes.io/docs/concepts/configuration/configmap/#configmaps-and-pods

This config map would provide the ./nginx.conf and ./nginx-cfg/*.conf files https://catalog.redhat.com/software/containers/rhel8/nginx-114/5ba0ada65a134643ef2eebcc

If we want to allow for some flexibility here the custom resource would need to have a section for the proxy where a config map could be mounted. Then that information would just be used during the deployment.

Automation hub current specifies the following: https://github.com/cutwater/automation-hub-deploy

The question I have here is what would the default nginx config look like? Some entries to pulp-api and pulp-content?

#10 Updated by fao89 10 months ago

I believe single container is the simplest example, We have a basic nginx.conf, and we include everything in pulp dir: https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf#L75

each plugin has its own snippet and we move it to nginx: https://github.com/pulp/pulp-oci-images/blob/latest/pulp/Containerfile#L25

as an example, here is the pulp_ansible snippet: https://github.com/pulp/pulp_ansible/blob/master/pulp_ansible/app/webserver_snippets/nginx.conf

#11 Updated by mdepaulo@redhat.com 10 months ago

Chris, very good idea.

Just note that the snippets canonically live in the plugins though, files within pip packages installed on the pulp container image. And the pulp-operator upstream will have many different possible plugins with different snippets. Do you have a strategy for getting them into the configmap?

And yeah, what Fabricio pointed to.

#12 Updated by chambridge 10 months ago

So from what I'm reading there isn't an existing image for the web server. There isn't anything in quay: https://quay.io/organization/pulp

So from the default experience we should decide what we'd want to deliver for pulp-operator upstream. I see 2 options: A) Use nginx default with the a config map only mounting https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf with no plugins B) Create a container similar to the CI containers that installs all the plugins and again mounting a config map with the nginx snippets for the used plugins

The CRD would have a proxy section with an image attribute and the volume mount mentioned above.

The image attribute would allow consumers to provide their nginx container where the pulp plugin has been installed; upstream via pip; downstream via rpm.

Thoughts?

#13 Updated by fao89 10 months ago

FYI, the nginx conf we provide on pulp_installer is more complex: https://github.com/pulp/pulp_installer/blob/master/roles/pulp_webserver/templates/nginx.conf.j2

I think if we decide to have something "usable" as fast as we can, I would go with option B and the simpler nginx conf we have at https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf

I particularly vote for going simple for now and addressing requests from users in the future

#14 Updated by mdepaulo@redhat.com 10 months ago

chambridge wrote:

So from what I'm reading there isn't an existing image for the web server. There isn't anything in quay: https://quay.io/organization/pulp

Correct, we haven't implemented it yet.

Quay has images built as part of pulp-operator's tree https://github.com/pulp/pulp-operator/tree/main/containers

So from the default experience we should decide what we'd want to deliver for pulp-operator upstream. I see 2 options: A) Use nginx default with the a config map only mounting https://github.com/pulp/pulp-oci-images/blob/latest/assets/nginx.conf with no plugins B) Create a container similar to the CI containers that installs all the plugins and again mounting a config map with the nginx snippets for the used plugins

The CRD would have a proxy section with an image attribute and the volume mount mentioned above.

The image attribute would allow consumers to provide their nginx container where the pulp plugin has been installed; upstream via pip; downstream via rpm.

Thoughts?

Let's go with B. Base the container image on the image used to build the all-4-services "pulp" image. An additional layer with the webserver.

#15 Updated by pulpbot 10 months ago

  • Status changed from NEW to POST

#16 Updated by chambridge 9 months ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100

Please register to edit this issue

Also available in: Atom PDF