从图像流在OpenShift Origin中部署特定的图像标签 [英] Deploying a specific image tag in OpenShift Origin from image stream

问题描述

我已经配置了Gitlab CI管道，以便它们使用Docker-in-Docker构建OCI映像并将其上传到Gitlab自己的注册表中.

I have configured my Gitlab CI pipelines so that they build an OCI image with Docker-in-Docker and upload it to Gitlab's own registry.

现在，我想将在CI管道中构建的映像部署到OpenShift Origin.注册表中的所有图像都用$CI_COMMIT_SHORT_SHA标记(即:我不使用最新").

Now, I want to deploy images built in my CI pipelines to OpenShift Origin. All images in the registry are tagged with $CI_COMMIT_SHORT_SHA (i.e.: I do not use "latest").

我该怎么做?

这是我到目前为止尝试过的:

This is what I have tried so far:

  before_script:
    - oc login --server="$OPENSHIFT_SERVER" --token="$OPENSHIFT_TOKEN"
    - oc project myproject
  script:
    - oc tag registry.gitlab.com/myproject/backend:$CI_COMMIT_SHORT_SHA backend:$CI_COMMIT_SHORT_SHA
    - oc import-image backend:$CI_COMMIT_SHORT_SHA
    - oc set image dc/backend backend=myproject/backend:$CI_COMMIT_SHORT_SHA
    - oc rollout latest backend

一切正常，直到oc set image.我希望它可以更改部署配置以使用指定的图像标记($CI_COMMIT_SHORT_SHA)，但是似乎配置并没有真正修改，因此，首次发布仍会部署旧的(上一个)图像.

Everything seems to work fine until oc set image. I would expect it to change the deployment configuration to use the specified image tag ($CI_COMMIT_SHORT_SHA), but it seems the configuration is not really modified and so, the rollout still deploys the old (previous) image.

我想念什么?是否有更好的方法从私有注册表中部署特定标签?

What am I missing? Is there a better way to deploy a specific tag from a private registry?

这是我的部署配置:

kind: DeploymentConfig
apiVersion: apps.openshift.io/v1
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftNewApp
  selfLink: /apis/apps.openshift.io/v1/namespaces/myproject/deploymentconfigs/backend
  resourceVersion: '38635053'
  name: backend
  uid: 02809a3d-...
  creationTimestamp: '2019-10-14T23:04:43Z'
  generation: 7
  namespace: myproject
  labels:
    app: backend
spec:
  strategy:
    type: Rolling
    rollingParams:
      updatePeriodSeconds: 1
      intervalSeconds: 1
      timeoutSeconds: 600
      maxUnavailable: 25%
      maxSurge: 25%
    resources: {}
    activeDeadlineSeconds: 21600
  triggers:
    - type: ConfigChange
    - type: ImageChange
      imageChangeParams:
        automatic: true
        containerNames:
          - backend
        from:
          kind: ImageStreamTag
          namespace: myproject
          name: 'backend:094971ea'
        lastTriggeredImage: >-
          registry.gitlab.com/myproject/backend@sha256:ebce...
  replicas: 1
  revisionHistoryLimit: 10
  test: false
  selector:
    app: backend
    deploymentconfig: backend
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: backend
        deploymentconfig: backend
      annotations:
        openshift.io/generated-by: OpenShiftNewApp
    spec:
      containers:
        - name: backend
          image: >-
            registry.gitlab.com/myproject/backend@sha256:ebce...
          ports:
            - containerPort: 8080
              protocol: TCP
          resources: {}
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: IfNotPresent
      restartPolicy: Always
      terminationGracePeriodSeconds: 30
      dnsPolicy: ClusterFirst
      securityContext: {}
      schedulerName: default-scheduler
status:
  observedGeneration: 7
  details:
    message: image change
    causes:
      - type: ImageChange
        imageTrigger:
          from:
            kind: DockerImage
            name: >-
              registry.gitlab.com/myproject/backend@sha256:ebce...
  availableReplicas: 1
  unavailableReplicas: 0
  latestVersion: 4
  updatedReplicas: 1
  conditions:
    - type: Available
      status: 'True'
      lastUpdateTime: '2019-10-14T23:57:51Z'
      lastTransitionTime: '2019-10-14T23:57:51Z'
      message: Deployment config has minimum availability.
    - type: Progressing
      status: 'True'
      lastUpdateTime: '2019-10-16T20:09:20Z'
      lastTransitionTime: '2019-10-16T20:09:17Z'
      reason: NewReplicationControllerAvailable
      message: replication controller "backend-4" successfully rolled out
  replicas: 1
  readyReplicas: 1

推荐答案

解决"的一种方法是ImageChange触发器侦听特定提交ID之外的内容. Docker中不存在作为标记的某些逻辑名称.说默认".

One way to "solve" this is that the ImageChange trigger listen to something other than a specific commit id. Some logical name that does not exist as a tag in docker. Say "default".

如果您这样做，那么在脚本中，唯一要做的就是

If you do that then in your script the only thing you need to do is

    - oc tag registry.gitlab.com/myproject/backend:$CI_COMMIT_SHORT_SHA backend:default

然后，OpenShift将负责更新DeploymentConfig中的映像并为您推出新的部署.

OpenShift will then take care of updating the image in the DeploymentConfig and rolling out a new deploy for you.

OP询问了为什么不使用最新的原因. Latest(最新)有点神奇"，因为如果您在没有标签的情况下推送到注册表中的图像，它将为该标签命名为Latest(最新).这使得意外覆盖非常容易.

OP asked for a reason why not using latest. Latest is kind of "magical" in that if you push to a image in a registry without a tag it will name that tag latest. This makes it very easy to overwrite it by accident.

因此，可以说您使用最新"作为您在ImageStream中收听的标签.如果有人导入imageStream会发生什么?它将获取最新标签，并覆盖您手动添加的标签.

So lets say you use "latest" as the tag that you listen to in the ImageStream. What happends if somebody imports the imageStream? It will fetch the latest tag an overwrite what you have manually tagged.

如果您想在管道中使用这种控件，请使用我上面所述的Docker注册表中不存在的ImageStreamTag名称.

If you want this kind of control in your pipeline use a ImageStreamTag name that does not exist in your docker registry like I said above.

这篇关于从图像流在OpenShift Origin中部署特定的图像标签的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！