Question

我有两个Openshift环境，我从Gitlab管道发布。让我们调用第一个DEV，它运行Openshift v3.7.1 + c2ce2c0-1。第二个是INT并运行v3.6.1 + 008f2d5。最近DEV从3.6.1升级到3.7.1，之后我注意到重新部署触发器的行为发生了奇怪的变化。

简而言之，我看到的是，当应用未更改的部署配置模板并且Docker镜像也保持不变时，将触发DEV环境中的现有部署以使用“已更改映像”消息进行重新部署。这意味着，例如，MongoDB或Jenkins部署会重新创建所有容器，并在每次运行CI管道时丢失所有数据。

是的，理论上有可能使用持久性卷，但Openshift安装不在我的控制之下。这里的重点是，当图像和配置都没有改变时，重新部署就会发生。

我从Gitlab使用的命令是：

oc process -f openshift-mongodb-ephemeral.yml -v MONGODB_DATABASE=mydb -v DATABASE_SERVICE_NAME=mongodb -l template=northbound-mongodb | oc apply -f -

以下是部署配置模板之一：

apiVersion: v1
kind: Template
labels:
  template: mongodb-ephemeral-template
metadata:
  annotations:
    description: |-
      MongoDB database service, without persistent storage. For more information about using this template, including OpenShift considerations, see https://github.com/sclorg/mongodb-container/blob/master/3.2/README.md.

      WARNING: Any data stored will be lost upon pod destruction. Only use this template for testing
    iconClass: icon-mongodb
    openshift.io/display-name: MongoDB (Ephemeral)
    tags: database,mongodb
  creationTimestamp: 2017-03-14T11:25:13Z
  name: mongodb-ephemeral
  resourceVersion: "483"
  selfLink: /oapi/v1/namespaces/openshift/templates/mongodb-ephemeral
  uid: e41b7f8e-08a8-11e7-9120-000d3a266151
objects:
- apiVersion: v1
  kind: Service
  metadata:
    creationTimestamp: null
    name: ${DATABASE_SERVICE_NAME}
  spec:
    ports:
    - name: mongo
      nodePort: 0
      port: 27017
      protocol: TCP
      targetPort: 27017
    selector:
      name: ${DATABASE_SERVICE_NAME}
    sessionAffinity: None
    type: ClusterIP
  status:
    loadBalancer: {}
- apiVersion: v1
  kind: DeploymentConfig
  metadata:
    creationTimestamp: null
    name: ${DATABASE_SERVICE_NAME}
  spec:
    replicas: 1
    selector:
      name: ${DATABASE_SERVICE_NAME}
    strategy:
      type: Recreate
    template:
      metadata:
        creationTimestamp: null
        labels:
          name: ${DATABASE_SERVICE_NAME}
      spec:
        containers:
        - capabilities: {}
          env:
          - name: MONGODB_USER
            value: ${MONGODB_USER}
          - name: MONGODB_PASSWORD
            valueFrom:
              secretKeyRef:
                key: database-password
                name: myproject-secrets
          - name: MONGODB_ADMIN_PASSWORD
            valueFrom:
              secretKeyRef:
                key: database-admin-password
                name: myproject-secrets
          - name: MONGODB_DATABASE
            value: ${MONGODB_DATABASE}
          image: ' '
          imagePullPolicy: IfNotPresent
          livenessProbe:
            initialDelaySeconds: 30
            tcpSocket:
              port: 27017
            timeoutSeconds: 1
          name: mongodb
          ports:
          - containerPort: 27017
            protocol: TCP
          readinessProbe:
            exec:
              command:
              - /bin/sh
              - -i
              - -c
              - mongo 127.0.0.1:27017/$MONGODB_DATABASE -u $MONGODB_USER -p $MONGODB_PASSWORD
                --eval="quit()"
            initialDelaySeconds: 3
            timeoutSeconds: 1
          resources:
            limits:
              memory: ${MEMORY_LIMIT}
          securityContext:
            capabilities: {}
            privileged: false
          terminationMessagePath: /dev/termination-log
          volumeMounts:
          - mountPath: /var/lib/mongodb/data
            name: ${DATABASE_SERVICE_NAME}-data
        dnsPolicy: ClusterFirst
        restartPolicy: Always
        volumes:
        - emptyDir:
            medium: ""
          name: ${DATABASE_SERVICE_NAME}-data
    triggers:
    - imageChangeParams:
        automatic: true
        containerNames:
        - mongodb
        from:
          kind: ImageStreamTag
          name: mongodb:${MONGODB_VERSION}
          namespace: ${NAMESPACE}
        lastTriggeredImage: ""
      type: ImageChange
    - type: ConfigChange
  status: {}
parameters:
- description: Maximum amount of memory the container can use.
  displayName: Memory Limit
  name: MEMORY_LIMIT
  required: true
  value: 512Mi
- description: The OpenShift Namespace where the ImageStream resides.
  displayName: Namespace
  name: NAMESPACE
  value: openshift
- description: The name of the OpenShift Service exposed for the database.
  displayName: Database Service Name
  name: DATABASE_SERVICE_NAME
  required: true
  value: mongodb
- description: Name of the MongoDB database accessed.
  displayName: MongoDB Database Name
  name: MONGODB_DATABASE
  required: true
  value: sampledb
- description: Version of MongoDB image to be used (2.4, 2.6, 3.2 or latest).
  displayName: Version of MongoDB Image
  name: MONGODB_VERSION
  required: true
  value: "3.2"
- description: Name of user to access MongoDB.
  displayName: MongoDB user
  name: MONGODB_USER
  required: true
  value: "mongouser"

每次执行Gitlab CI管道时都会执行 oc进程和 oc apply 命令。只要有人合并到例如，管道就会触发开发分支。我想保留这种行为，因为这可以保证如果有人更改MongoDB，Jenkins等的配置，那么会自动更新和重新部署（在这种情况下可以接受数据丢失）。

是否有人知道操作系统中的哪些更改可能会促使行为发生这种变化以及如何再次实现旧行为？

Answer 1

致信Graham Dumpleton并回答了我的问题，尽管通过评论。因为我没有收到他的回复，所以我自己也要留下这个答案，以便完整。缘故。

删除条目后

creationTimestamp
lastTriggeredImage
状态
图像

从部署配置模板

，停止了不需要的重新部署。我不知道哪个条目特别开始触发Openshift 3.7.1中的行为，但无论如何，这四个条目是在Openshift部署过程中生成的信息，不应该在模板中开始。

Openshift：3.6.1和3.7.1之间触发行为的变化

1 个答案: