2

I have a Skaffold file like this:


apiVersion: skaffold/v4beta1
kind: Config
build:
  artifacts:
  - image: app/auth
    context: auth
    sync:
      manual:
      - src: src/**/*.ts
        dest: .
    docker:
      dockerfile: Dockerfile

And deploymant files like following:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auth
  template:
    metadata:
      labels:
        app: auth
    spec:
      containers:
        - name: auth
          image: app/auth
          env:
            - name: MONGO_URI
              value: 'mongodb://auth-mongo-srv:27017/auth'
            - name: JWT_KEY
              valueFrom:
                secretKeyRef:
                  name: jwt-secret
                  key: JWT_KEY

---
apiVersion: v1
kind: Service
metadata:
  name: auth-srv
spec:
  selector:
    app: auth
  ports:
    - name: auth
      protocol: TCP
      port: 3000
      targetPort: 3000

With a Dockerfile like below:


FROM node:alpine

WORKDIR /app
COPY package.json .
RUN npm install --only=prod
COPY . .

CMD ["npm", "start"]


But after running skaffold dev I see a list of docker images like this:

REPOSITORY                       TAG                                                                IMAGE ID       CREATED             SIZE
app/auth               429eadf4af2ad66af9f364eb3cfe8926e05276c4f579fe39c5112e3201b1e4ac   429eadf4af2a   15 minutes ago      345MB
app/auth               latest                                                             429eadf4af2a   15 minutes ago      345MB

Is it normal to have 2 different images for each container?

best_of_man
  • 367
  • 1
  • 3
  • 12
  • 1
    Looks Skaffold maintains two tags (with the same Image IDs)when building to the local docker daemon. Please check the similar [SO](https://stackoverflow.com/questions/68185780) for more information to resolve your issue. – Veera Nagireddy Jan 17 '23 at 00:33
  • @VeeraNagireddy: So it seems they're OK and no need to fix them? – best_of_man Jan 17 '23 at 00:52
  • 1
    With Helm, scaffold will take care to "override" that untagged image with a tagged one and your deployment is always up to date as per the Ref SO comments. – Veera Nagireddy Jan 17 '23 at 00:59

1 Answers1

3
After referring to a lot of documents it seems they're OK and no need to fix them.

Running a skaffold build command triggers an image build, which results in an image with two tags;

One with the most recent git tag or git commit (e.g. my-app:ae7926d), and as the image isn't pushed to a container registry, a tag which uses the 64 character ID of the image.

Skaffold is big on image immutability, and the latter tag is a content addressable reference to the image in the local cache. If it had been pushed to a registry, the immutable reference would be the image's digest instead.

This ensures we only use the image Skaffold has built, and not a nefarious image masquerading as one and the same.

As well as providing flexibility on the method of build that we mentioned earlier (i.e. Docker, Jib and so on), Skaffold can accommodate different locations for performing image builds. They can be performed locally, inside a Kubernetes cluster (using Kaniko), or remotely using (unsurprisingly) Google Cloud Build.

Please go through Developing for Kubernetes with Skaffold (Building images) for more information.

Also see the similar SO which is clearly explained about Why does Skaffold maintain two tags when building to the local docker daemon?

Tags are cheap: they're like symlinks, pointing to an image identifier.

Skaffold can't just use the computed image tag as many tag conventions do not produce unique tags and the tag can be overwritten by another developer and point to a different image. It's not unusual for a team of devs, or parallel tests, to push images into the same image repository and encounter tag clashes.

Veera Nagireddy
  • 523
  • 2
  • 6