Deis sets readinessProbe to some Apps

[arkkanoid]

Today I've installed a new fresh version of Deis (v2.3.0).
I've tested some PHP-based Dockerfiles that I ran in v2.0 and I get an error deploying the app:

Readiness probe failed: dial tcp 10.2.19.2:5000: connection refused

The application runs, but fails due to the readiness probe.
The most interesting thing is that I haven't configured any healthcheck.
Trying a simpliest Nginx app I can deploy it successfully.
The Dockerfile I use exposes to port 80 and have a CMD.

Running:

deis healthchecks -a marble-jailbird
=== marble-jailbird Healthchecks

--- Liveness
No liveness probe configured.

--- Readiness
No readiness probe configured.

The Schema that Deis generates is:

apiVersion: v1
kind: ReplicationController
metadata:
  creationTimestamp: 2016-08-17T14:11:17Z
  generation: 2
  labels:
    app: marble-jailbird
    heritage: deis
    type: cmd
    version: v3
  name: marble-jailbird-v3-cmd
  namespace: marble-jailbird
  resourceVersion: "9283922"
  selfLink: /api/v1/namespaces/marble-jailbird/replicationcontrollers/marble-jailbird-v3-cmd
  uid: 76db6cd7-6484-11e6-a1db-06b8ff01bfc7
spec:
  replicas: 1
  selector:
    app: marble-jailbird
    heritage: deis
    type: cmd
    version: v3
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: marble-jailbird
        heritage: deis
        type: cmd
        version: v3
      name: marble-jailbird-v3-cmd
    spec:
      containers:
      - env:
        - name: DEIS_APP
          valueFrom:
            secretKeyRef:
              key: deis-app
              name: marble-jailbird-v3-env
        - name: PORT
          valueFrom:
            secretKeyRef:
              key: port
              name: marble-jailbird-v3-env
        - name: WORKFLOW_RELEASE
          valueFrom:
            secretKeyRef:
              key: workflow-release
              name: marble-jailbird-v3-env
        image: XXXXXX.dkr.ecr.eu-west-1.amazonaws.com/marble-jailbird:git-7a486354
        imagePullPolicy: Always
        name: marble-jailbird-cmd
        readinessProbe:
          failureThreshold: 1
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          tcpSocket:
            port: 5000
          timeoutSeconds: 5
        resources: {}
        terminationMessagePath: /dev/termination-log
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: private-registry-ecr
      restartPolicy: Always
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  fullyLabeledReplicas: 1
  observedGeneration: 2
  replicas: 1

[bacongobbler]

This is intentional by design. If you do not explicitly opt into healthchecks, one is supplied anyways. Use deis config:set PORT=80 so the healthcheck will check the correct port, though I think this is a bug since the controller should determine the correct port assuming it's a Dockerfile or a deis pull image. ping @helgi

[helgi]

That's a private image - when that's the case the API tells you to set a PORT

Was the private registry set up for the whole platform or using registry:set?

[bacongobbler]

Ah I had assumed from the OP

The Dockerfile I use exposes to port 80 and have a CMD.

So I had assumed it was a Dockerfile push. Thanks for the clarification, @helgi.

In this case, the PORT envvar case for private images is documented at https://deis.com/docs/workflow/applications/using-docker-images/#private-registry:

When using a private registry the docker images are no longer pulled into the Deis Internal Registry via the Deis Workflow Controller but rather is managed by Kubernetes. This will increase security and overall speed, however the port information can no longer be discovered. Instead the port information can be set via deis config:set PORT=80 prior to setting the registry information.

Does this along with the explanation in #409 (comment) about why we supply healthchecks by default answer your original question, @arkkanoid? Perhaps the solution here is to somehow utilize the healthchecks model itself in the controller when an app is deployed instead of making it hidden?

[arkkanoid]

Setting deis config:set PORT=80, or deis healthchecks:set liveness httpGet 80 works.
What I don't understand is why a simple Go application with the same default healthcheck to port 5000 works:

cat Dockerfile 
FROM debian:jessie

# install curl
RUN apt-get update && apt-get install -qy curl

# install go runtime
RUN curl -s https://storage.googleapis.com/golang/go1.2.2.linux-amd64.tar.gz | tar -C /usr/local -xz

# prepare go environment
ENV GOPATH /go
ENV GOROOT /usr/local/go
ENV PATH $PATH:/usr/local/go/bin:/go/bin

# add the current build context
ADD . /go/src/github.com/deis/helloworld

# compile the binary
RUN cd /go/src/github.com/deis/helloworld && go install -v .

EXPOSE 80

ENTRYPOINT ["/go/bin/helloworld"]


kubectl describe pod/gaslit-backbone-v3-cmd-01xz2 --namespace=gaslit-backbone
Name:   gaslit-backbone-v3-cmd-01xz2
Namespace:  gaslit-backbone
Node:   ip-10-0-0-252.eu-west-1.compute.internal/10.0.0.252
Start Time: Wed, 17 Aug 2016 16:51:12 +0200
Labels:   app=gaslit-backbone,heritage=deis,type=cmd,version=v3
Status:   Running
IP:   10.2.19.5
Controllers:  ReplicationController/gaslit-backbone-v3-cmd
Containers:
  gaslit-backbone-cmd:
    Container ID: docker://49fcc943f444ce21a3add50fa6481e54a95fd75b70b2754b02788c3c7540b21f
    Image:    XXXXXX.dkr.ecr.eu-west-1.amazonaws.com/gaslit-backbone:git-728423dd
    Image ID:   docker://sha256:d521433dd89fd019a8f710022d3c719147c29d158dd3c02536c2d8fea3a60ce3
    Port:   
    QoS Tier:
      cpu:    BestEffort
      memory:   BestEffort
    State:    Running
      Started:    Wed, 17 Aug 2016 16:51:12 +0200
    Ready:    True
    Restart Count:  0
    Readiness:    tcp-socket :5000 delay=5s timeout=5s period=5s #success=1 #failure=1
    Environment Variables:
      DEIS_APP:   
      PORT:   
      WORKFLOW_RELEASE: 
Conditions:
  Type    Status
  Ready   True 
Volumes:
  default-token-1cer9:
    Type: Secret (a volume populated by a Secret)
    SecretName: default-token-1cer9
No events. 

[helgi]

The way the internal logic works (right now) is that port 5000 is returned when we can not determine the appropriate port.

When using registry:set we intentionally require you to set PORT, however you seem to have set up your private registry via our new Native Registry support. The Controller did not account for that new scenario and was letting you deploy without setting a PORT - I'm fixing that now.

The reason for this is the Controller is no longer pulling the image to the internal registry or is the builder pushing it to the internal one, but rather to your external one. For speed and security purposes we decided not to pull in the image to discover the port, and the intention was not to try to have a default port.

Apologises for that oversight.

[arkkanoid]

THanks @helgi

[helgi]

Fix is at deis/controller#988