Ghost image not usable anymore

mag1

Hi all,

I just noticed that the "ghost" image is not usable anymore. It will deploy but spinning the pod will fail:

`[023-03-27 09:59:34] INFO Ghost is running in production...
[2023-03-27 09:59:34] INFO Your site is now available on http://localhost:2368/
[2023-03-27 09:59:34] INFO Ctrl+C to shut down
[2023-03-27 09:59:34] INFO Ghost server started in 0.785s
[2023-03-27 09:59:34] ERROR connect ECONNREFUSED 127.0.0.1:3306

connect ECONNREFUSED 127.0.0.1:3306

"Unknown database error"

Error ID:
500

Error Code:
ECONNREFUSED

---

Error: connect ECONNREFUSED 127.0.0.1:3306
at /var/lib/ghost/versions/5.40.1/node_modules/knex-migrator/lib/database.js:57:19
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1278:16)

[2023-03-27 09:59:34] WARN Ghost is shutting down
[2023-03-27 09:59:34] WARN Ghost has shut down
[2023-03-27 09:59:34] WARN Your site is now offline
[2023-03-27 09:59:34] WARN Ghost was running for a few seconds
`

It seems that a running mandatory mysql/mariaDB is hardwired into the images code.

Not sure on how to proceed here.
Either use a different image/app (e.g. nginx, git, hlds ...) or
re-write the helm manifest so a mariaDB will also be deployed or
fix the image so if no DB is available the pod will still spin up ... ?

mag1

So, ... since NOBODY replied to my question, I had to figured it out by myself.
So here is the yaml that will deploy a pod with two containers ghost and mariaDB.

However, the Pod will come up successfully but will fail (after a minute or so) because mariaDB creates a fresh and completely empty database, thus ghost can't read anything from it.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sadako
spec: # specification for deployment resource
  selector:
    matchLabels:
      app: sadako
  template:
    metadata:
      labels:
        app: sadako
    spec: # specification for Pods
      containers:
      - name: mariadb
        image: bitnami/mariadb
        env:
        - name: MARIADB_ROOT_PASSWORD
          value: secret
      - name: ghost
        image: bitnami/ghost
        ports:
        - containerPort: 80
        env:
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"

chrispokorni

Hi @mag1,

Would you be able to provide the section in the lab guide where the ghost image is referenced?

Regards,
-Chris

mcdueerkop

Hi @chrispokorni

I am stumbleing over the same error as @mag1 in the course material. I have jet to view the lab guides. I am following along in the Chapter 11 Ingress of the course in the slide "Creating an Ingress Rule".

It contains the following 2 commands:
$ kubectl run ghost --image=ghost
$ kubectl expose deployments ghost --port=2368

The seccond one also fails as the first one does not create a deployment, it only creates a pod.

Hope this helps.
And thanks @mag1 for creating the YAML, will use/replikate it now.

Have a nice Easter Weekend!

Best Regards,

McDueerkop

mcdueerkop

Hi @mag1

Sadly i could not "plug & play" your template into my env.
I always got an error message that the ghost image could not connect to the mariadb instance even though it was running in the same pod.

I made some modifications:

1. Use the official docker images.
2. Pass the development variable into the ghost image, to ensure it starts up as a dev enviornment.

Here is the complete yml for review:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ghost
spec:
  selector:
    matchLabels:
      app: ghost
  template:
    metadata:
      labels:
        app: ghost
    spec:
      containers:
      - name: mariadb
        image: mariadb
        env:
          - name: MARIADB_ROOT_PASSWORD
            value: my-secret-pw
      - name: ghost
        image: ghost
        ports:
        - containerPort: 2368
        env:
          - name: NODE_ENV
            value: development

Best Regards,

McDueerkop

chrispokorni

Hi @mag1 and @mcdueerkop,

I would recommend following exercises from the lab guide for hands-on experience. Some of the illustrative commands from the lectures section may not work if applied directly as presented.

Regards,
-Chris

mag1

@chrispokorni said:
Hi @mag1 and @mcdueerkop,

I would recommend following exercises from the lab guide for hands-on experience. Some of the illustrative commands from the lectures section may not work if applied directly as presented.

Regards,
-Chris

See, that's actual the problem. Those exercises include "packages" like ghost and therefore fail without a hint from the text.

chrispokorni

Hi @mag1,

Would you be able to provide the lab exercise number and step number where the ghost image is referenced and fails?

Regards,
-Chris

mag1

Hi, sorry for the late reply.
Indeed I couldn't find any appearances of "ghost" in any lab-exercise (pdf documents).
But if you go to chapter 7 (Managing State with Deployments) Section: Managing State with Deployments -> Deployment Rollbacks (page: 10) ... here it is used multiple times.

akesterson

I just hit the same issue. The text of Chapter 11, "Creating an Ingress Rule", sets a clear expectation with the reader that the code presented should work.

To get exposed with ingress quickly, you can go ahead and try to create a similar rule as mentioned on the previous page. First, start a ghost deployment and expose it with an internal ClusterIP service. See the following commands:

$ kubectl run ghost --image=ghost
$ kubectl expose deployments ghost --port=2368

If this should not be taken literally, it should not use literal language issuing directives for the reader to follow along. The fact that this has been a known issue for a year and the paid course still includes the example with the bug is frustrating.