Pulp in kubernetes without operator

Support
#1

Problem:
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:
latest

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,
Pasha

1 Like
#2

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

#3

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:

2 Likes
#4

@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!

#5

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:

https://docs.google.com/presentation/d/14WRD9Erjbx8E8zAb44ajCt6YYUVWnKB6cfEd17XEgwE/edit?usp=drivesdk
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:

env:
  # 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_AWS_QUERYSTRING_AUTH: "true"
  PULP_AWS_S3_SIGNATURE_VERSION: s3v4
  # PULP_AWS_S3_CUSTOM_DOMAIN:
  PULP_CONTENT_ORIGIN: https://example.com
  PULP_CONTENT_PATH_PREFIX: /
  PULP_DEFAULT_FILE_STORAGE: storages.backends.s3boto3.S3Boto3Storage
  PULP_FILE_UPLOAD_TEMP_DIR: /tmp
  PULP_MEDIA_ROOT: ""
  PULP_S3_USE_SIGV4: "true"
  PULP_REDIS_DB: 1
  PULP_AUTHENTICATION_BACKENDS: "['pulpcore.app.authentication.PulpNoCreateRemoteUserBackend']"
  PULP_REST_FRAMEWORK__DEFAULT_AUTHENTICATION_CLASSES: "['pulpcore.app.authentication.PulpRemoteUserAuthentication']"
  PULP_REMOTE_USER_ENVIRON_NAME: HTTP_REMOTE_USER
  PULP_CONTENT_WORKERS: 9
  # 7 days is max for v4 signatures
  PULP_AWS_QUERYSTRING_EXPIRE: 604800
  PULP_TOKEN_AUTH_DISABLED: "true"
  # use old worker style for now
  PULP_USE_NEW_WORKER_TYPE: "false"
3 Likes
#6

Hi @ep4sh, is been a while since your post, but we have an update. At the time the post was created we had ansible-based operator with which was not possible to use an external service of Redis or Postgres, however recently we’ve been working on an overhaul of pulp-operator towards a go-based one which enabled us to add a configuration to use external cloud services like Postgres or Redis among other features.
Was this the primary obstacle for you from using Operator or you specifically were looking into using Helm charts? If it was the former then we’re pretty close to a go-based pulp-operator release and if you’re interested to see more info or capabilities which have been added please take a look here Pulp Operator and let us know what you think!

3 Likes