Welcome to the Linux Foundation Forum!

Ghost image not usable anymore

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,367

    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,367

    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,367

    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 3

    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.

Categories

Upcoming Training