Pulp in kubernetes without operator

Running Pulp in k8s without operator using cloud services (S3/Redis/Postgres).

Expected outcome:
Pulp is deployed in k8s using helm charts without an operator.

Pulpcore version:

Pulp plugins installed and their versions:

  • debian
  • rpm

Operating system - distribution and version:
Kubernetes installation

Other relevant data:
Hey folks, I was interested in the Pulp project and I want to spin it up in the Kubernetes environment.

As I could see there is a k8s operator: https://github.com/pulp/pulp-operator
but I am curious about deploying pulp without the operator since I can use some external cloud services like Postgres, Redis, S3 storage, and so on for application state.

I wonder if you could suggest if it is reasonable to spin up the pulp application using the external “state services” and using helm charts for pulp application.
In other words - does the pulp (or it’s core modules/plugins especially like Deb/RPM), store state anywhere (instead of redis/posgres)? Can I avoid using the operator or there are any pitfalls?

I’d really appreciate any advice.

Thank you,

There was a follow-up discussion on Matrix. Some results might get posted here.

I don’t have matrix access where I’m currently at, but I can tell you that I’ve been running Pulp in production on EKS (with rds and s3; bitnami redis instead of elasticache though) for just about a year now. Works great.

Our Docker images are public, but not official and not quite current version (I’m working on getting better about that second part). My helm chart is not yet public - mostly because I haven’t had time to separate out the data, but also partially because some things like secrets and RDS db operator are specific to our environment and partially because I haven’t officially gotten legal’s approval to release it. https://github.com/Kong/docker-pulp

I’d be happy to answer any questions you have, other than “can I have the helm chart” :slight_smile:

1 Like

@dannysauer thank you very much for the details. I looking for info on how to disable internal SSL - we’re going to terminate SSL on the LB. Appreciate it if you can share your experience. (so far I found the info that SSL is being generated and applied on the installation stage). But yes, it doesn’t relate to the current topic. Thanks!

It doesn’t hurt to use different SSL internally from the ingress to the container, but what we do is to not run the installer at all (which brings its own issues). We use an entry point which simply launches Green Unicorn: https://github.com/Kong/docker-pulp/blob/main/pulp-content/entrypoint.sh after building the container by pip installing the packages in a virtenv. All configuration is done with env variables, managed through the helm chart.

We talked about the setup at Pulpcon this year:

That may or may not be useful watching to augment the code. I don’t consider myself a super-engaging speaker. :smiley:

Here’s pretty much the whole config we use, which includes doing auth at the ingress instead of at Pulp:

  # note: env booleans MUST BE LOWERCASE
  # "false" is boolean false, "False" is a string which is true
  # alternative is to use "@bool False" if you simply must upper-case the letter
  PULP_ADMIN_PASSWORD: REDACTED # pragma: allowlist secret
  PULP_AWS_LOCATION: pulp3-media      # prefix for S3 object path
  PULP_AWS_S3_REGION_NAME: us-east-2  # default region for S3
  PULP_CONTENT_ORIGIN: https://example.com
  PULP_DEFAULT_FILE_STORAGE: storages.backends.s3boto3.S3Boto3Storage
  PULP_S3_USE_SIGV4: "true"
  PULP_AUTHENTICATION_BACKENDS: "['pulpcore.app.authentication.PulpNoCreateRemoteUserBackend']"
  PULP_REST_FRAMEWORK__DEFAULT_AUTHENTICATION_CLASSES: "['pulpcore.app.authentication.PulpRemoteUserAuthentication']"
  # 7 days is max for v4 signatures
  # use old worker style for now