Welcome to the Linux Foundation Forum!

Ghost image not usable anymore

mag1
mag1 Posts: 7
in LFS258 Class Forum

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 ... ?

Comments

  • mag1
    mag1 Posts: 7
    edited March 2023

    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
    chrispokorni Posts: 2,592

    Hi @mag1,

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

    Regards,
    -Chris

  • mcdueerkop
    mcdueerkop Posts: 5
    edited April 2023

    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
    mcdueerkop Posts: 5
    edited April 2023

    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
    chrispokorni Posts: 2,592

    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
    mag1 Posts: 7

    @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
    chrispokorni Posts: 2,592

    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
    mag1 Posts: 7

    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
    akesterson Posts: 1
    edited May 2024

    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.

  • ernestr
    ernestr Posts: 1
    edited August 2025

    Bumping this as the most basic example of using ghost in Managing State with Deployments still fails.

    $ kubectl create deploy ghost --image=ghost
$ kubectl logs ghost-c549745c4-wh4t6 
[2025-08-27 02:07:38] INFO Ghost is running in production...
[2025-08-27 02:07:38] INFO Your site is now available on http://localhost:2368/
[2025-08-27 02:07:38] INFO Ctrl+C to shut down
[2025-08-27 02:07:38] INFO Ghost server started in 0.298s
[2025-08-27 02:07:38] 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/6.0.5/node_modules/knex-migrator/lib/database.js:57:19
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16)

    Maybe pick a more self contained example deployment?

    @mcdueerkop thanks. Your dev manifest worked for me.

Categories

Upcoming Training