mschau's questions

I've got following scenario: One Docker Host with several CMS projects and a Traefik up and running. I'd like to filter out the backend URL from Public IP addresses, since it should only be accessible from private IP Ranges.

publicly available: https://www.project.com/xyz https://www.project.com/abc

restricted to internal IP's only: https://www.project.com/backend

Can I realize that with an IP whitelist and e.g. 2 Routers - 1 for public access and 1 for backend access?

I've tried something like:

  # Backend Router (Restricted Access)
  - "traefik.http.routers.project-backend.rule=Host(`${DOMAINNAME}`) && PathPrefix(`/backend`)"
  - "traefik.http.routers.project-backend.entrypoints=https"
  - "traefik.http.routers.project-backend.tls=true"
  - "traefik.http.routers.project-backend.middlewares=backend-ipwhitelist"
  - "traefik.http.routers.project-backend.priority=100"

But the filter didn't work - could still access backend.

Any suggestions?

We've got following on-prem scenario: Devs working in Bitbucket on Apps, Ops working in Gitlab for "Gitops" things. We'd like to automate builds and deployment via our Gitlab pipeline and looking for ways to implement. The build part already works. But we'd like to distinguish between branches - not every branch should be deployed - especially production would be manually deployed.

Since the webhook contains the branch I've tried to set in deployment stage:

only:
  - dev

as well as

  rules:
    - if: '$TOKEN_BRANCH != $PROD_BRANCH'

But in both ways the deployment pipeline is still triggered.

Two workarounds came in my mind:

One option would be to mirror the bitbucket repository via "post commit hook" - but on one hand this plugin is with costs and on the other hand you need a second plugin for the mirroring - and the only I can find isn't maintained any longer.

Second option would be to license Gitlab Ultimate to be able to use "pull mirroring" which could also be triggered via Bitbucket webhook.

Since we have no use on repository mirroring and the only use case would be to be able to use the Gitlab pipeline on a "local repository" where all the above ways to differ the branch for deployment should work - I'd prefer to find a way with already available ressources.

Happy to hear your thoughts about this!

EDIT: parts of the pipeline:

variables:
  PROD_BRANCH: main

before_script:
  - TOKEN_BRANCH=$(cat $TRIGGER_PAYLOAD | jq -r '.changes[0].ref.displayId')

deploy:
  stage: deploy
  tags:
    - openshift
  rules:
    - if: $TOKEN_BRANCH != $PROD_BRANCH

• echo $TOKEN_BRANCH returns "main".
• in rules: this part of the pipeline is only triggered if the following statement is true.
• Since "main == main" and not "!=" the "deploy" stage of the pipeline shouldn't be executed. But it is...

several variants

rules:
  - if: '$TOKEN_BRANCH !~ $PROD_BRANCH'

rules:
  - if: '$TOKEN_BRANCH =~ $PROD_BRANCH'
    when: never

in these cases the opposite happens - the pipeline never has a deploy stage - it even does not show the stage in "pipelines" view in Gitlab.

I'd like to provide for our disconnected container infrastructure (OKD, Harbor) several base images, which are automatically weekly renewed (re-created) and images older than XX days are pruned.

For that I've adopted a script which creates a centos base image, imports it into the local docker registry (docker import tar file) and pushes it to harbor afterwards.

Now I'd like to add a logic to prune only the images in that specific repository and only images older than XX days.

For that I've tried several variants of the "docker image prune" command and setting filters - for my understanding I could set filters like:

docker image prune --filter "until=$(date +'%Y-%m-%dT%H:%M:%S' --date='-60 days')" --filter "label=Repository=centos_base:*"

#docker images
REPOSITORY                                                    TAG        IMAGE ID       CREATED        SIZE
centos_base                                                   7.9.2009   54ab4ae0746a   10 hours ago   283MB

But the filter with label seems not to work in that way:

# docker image ls --filter "label=centos_base"
REPOSITORY   TAG       IMAGE ID   CREATED   SIZE

So I would try now to set labels on the base_images, but that assumes that you use a Dockerfile, which seems a bit to cumbersome for my purposes.

Is there a way to add the labels during import or afterwards, or is there a completely different and more practical way for this?

How do you handle this topic?