[{"_1":2,"_151":-5,"_152":-5},"loaderData",{"_3":4,"_13":14,"_20":21,"_130":131},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","routes/_layout.r.$namespace.$reponame",{"_22":23,"_24":-5,"_25":11,"_26":11,"_27":28,"_29":30,"_31":-5,"_32":11,"_33":34,"_83":-5,"_84":85,"_123":-5,"_124":11,"_125":17,"_126":11,"_127":-5,"_128":129},"canonicalUrl","https://hub.docker.com/r/markdumay/ghost/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","markdumay","reponame","ghost","cloudBuildSource","isAutobuildsAvailable","repo",{"_35":36,"_37":38,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":50,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":69,"_74":11,"_75":76,"_80":28,"_81":82},"categories",[],"content_types",[39],"image","date_registered","2020-06-24T06:39:16.587572Z","description","","is_private","last_updated","2020-10-29T15:25:52.551409Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[51],"application/vnd.docker.container.image.v1+json","name","pull_count",332,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# ghost-backend\n\n\n

\n Deploy a Ghost Blog as Back-End Docker Service\n
\n

\n\n\n\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

\n\n\n

\n About •\n Built With •\n Prerequisites •\n Testing •\n Deployment •\n Usage •\n Contributing •\n Credits •\n Donate •\n License\n

\n\n\n## About\n[Ghost][ghost_info] is a popular open source Content Management System (CMS) based on Node.js. It was founded in 2013 and has seen more than 2 million installations to date. The team behind Ghost offers a managed service that gets you started in minutes. However, in this guide, we will be looking into self-hosting Ghost as a back-end service on a Virtual Private Server (VPS). The final configuration aims to be both secure and scaleable.\n\n\n\n## Built With\nThe project uses the following core software components:\n* [Docker][docker_url] - Container platform (including Swarm and Compose)\n* [Ghost][ghost_url] - Content Management System\n* [HTTPS Portal][portal_url] - Fully automated HTTPS server\n* [MariaDB][mariadb_url] - Community-developed fork of MySQL relational database\n* [Mysqldump][mysqldump] - Open-source tool provided by MariaDB to export a database\n* [Restic][restic_url] - Backup program with cloud storage integration\n\n## Prerequisites\n*Ghost-backend* can run on a local machine for testing purposes or in a production environment. The setup has been tested locally on macOS and a Virtual Private Server (VPS) running Ubuntu 20.04 LTS. The cloud backup functionality has been tested with [Backblaze B2].\n\n### Recommended Server Sizing\nGhost is a relatively light-weight application that requires 1 GB of memory. \n\n### Host Operating System\nMost VPS providers offer several Linux distributions to be installed on your VPS. Although Docker and Ghost are compatible with many of them, Ghost recommends Ubuntu 16.04 LTS or Ubuntu 18.04 LTS. The Long Time Support (LTS) edition is the most stable version and is the recommended environment for a production system.\n\n### Other Prerequisites\n* **A registered domain name is required** - Not only will this help people to find your blog, but it is also required for configuring SSL certificates to enable secure traffic via https. You should have the ability to manually configure DNS entries for your domain too.\n\n* **Docker Compose and Docker Swarm are required** - Ghost and the MariaDB Database will be deployed as Docker containers in swarm mode to enable Docker secrets. This [repository][ubuntu-docker] provides a script to harden the host and to deploy Docker securely.\n\n* **A (cloud) backup service is highly recommended** - To enable versioning and disaster recovery, an offsite backup is highly recommended. Restic provides [integrations][restic_integration] for Amazon S3, Minio Server, Openstack Swift, Backblaze B2, Microsoft Azure Blob Storage, and Google Cloud Storage. Other methods include SFTP, REST Server, or rclone. This guide uses Backblaze B2 as an example.\n \n\n* **An email service is optional** - Having an email service allows you to receive system notifications from Ghost.\n\n\n## Testing\nIt is recommended to test the services locally before deploying them to production. Running the service with `docker-compose` greatly simplifies validating everything is working as expected. Below four steps will allow you to run the services on your local machine and validate it is working correctly.\n\n### Step 1 - Clone the Repository\nThe first step is to clone the repository to a local folder. Assuming you are in the working folder of your choice, clone the repository files. Git automatically creates a new folder `ghost-backend` and copies the files to this directory. The option `--recurse-submodules` ensures the embedded submodules are fetched too. Change to your working folder once done to be prepared for the next steps.\n\n```console\ngit clone --recurse-submodules https://github.com/markdumay/ghost-backend.git\ncd ghost-backend\n```\n\n### Step 2 - Create Docker Secrets\nAs `docker-compose` does not support external Swarm secrets, we will create local secret files for testing purposes. \n\n```console\nmkdir secrets\nprintf password > secrets/db_root_password\nprintf ghost > secrets/db_user\nprintf password > secrets/db_password\nprintf ghost_backup > secrets/db_backup_user\nprintf password > secrets/db_backup_password\nprintf password > secrets/restic_password\n```\n\nNext, you will need to configure the tokens required to connect with your cloud storage provider. The below example defines the tokens for [Backblaze B2]. *Ghost-backend* automatically stages any Docker secret starting with the prefix `STAGE_`. In below example, `STAGE_B2_ACCOUNT_ID` becomes available as `B2_ACCOUNT_ID` for restic. This [link][restic_integration] provides an overview of the tokens required for each supported cloud provider. Be sure to replace `XXX` with the correct values.\n\n```console\nprintf XXX > secrets/STAGE_B2_ACCOUNT_ID\nprintf XXX > secrets/STAGE_B2_ACCOUNT_KEY\n```\n\n### Step 3 - Update the Environment Variables\nThe `docker-compose.yml` file uses environment variables to simplify the configuration. You can use the sample file in the repository as a starting point.\n\n```console\nmv sample.env .env\n```\n\n> It's convenient to use a `.test` top-level domain for testing. This domain is reserved for this purpose and is guaranteed not to clash with an existing domain name. However, you will still need to resolve these domains on your local machine. Steven Rombauts wrote an excellent [tutorial][macos_dnsmasq] on how to configure this using `dnsmasq` on macOS.\n\n\nThe `.env` file specifies eleven variables. Adjust them as needed:\n\n\n| Variable | Default | Description |\n|-----------------------|----------------------|-------------|\n| **DOMAINS_BLOG** | `example.test` | Defines the domain name of your blog. Exclude the `http://` and `https://` protocols. |\n| **DOMAINS_ADMIN** | `admin.example.test` | Defines the admin domain name of your blog. Exclude the `http://` and `https://` protocols. |\n| **DB_NAME** | `ghost` | The name of the database to be used by Ghost and MariaDB. |\n| **DB_USER** | `ghost` | The name of database user to be used by Ghost when connecting with MariaDB. Ensure it is the same value as the secret `db_user`. |\n| **ADMIN_EMAIL** | `admin@example.test` | Email address for notifications from Ghost and Let's Encrypt.\n| **THEMES** | `true` | Indicates whether the default Ghost theme (Casper) should be installed.\n| **BACKUP** | `remote` | Indicates whether to schedule backups automatically. Settings can be either `none` for no backups, `local` for local backups only, or `remote` for both local and remote backups.\n| **RESTIC_REPOSITORY** | `b2:bucketname:/` | The storage provider and bucket name of the remote repository. For Backblaze B2, the full identifier is `b2:bucketname:path/to/repo`. The identifier for other storage providers can be found [here][restic_integration].\n| **GHOST_HOST** | `ghost:2368` | Specifies the localhost and port of the Ghost server. The default port is 2368.\n| **STAGE** | `local` | Instructs HTTPS Portal to request certificates from Let's Encrypt when set to `production`. When set to `local`, HTTPS Portal installs self-signed certificates for local testing.\n| **CACHING** | `true` | Instructs Nginx to cache static files such as images and stylesheets if set to 'true'. The admin portal remains uncached at all times.\n\n\n\n### Step 4 - Run Docker Service\nTest the Docker services with `docker-compose`.\n\n```console\ndocker-compose up\n```\n\nAfter pulling the images from the Docker Hub, you should see several messages. Below excerpt shows the key messages per section.\n\n#### Enabling Automated Backups\nDuring boot, *Ghost-backend* enables the local and remote backups in line with the `BACKUP` setting (see Step 3). First, the cron job using `mysqldump` for local backups is scheduled 30 minutes past every hour. Next, the latest `restic` binary is downloaded and installed (`mysqldump` is already present in the parent's Docker image provided by MariaDB). Once restic is installed, it is scheduled to run 45 minutes past every hour. Restic compares the local files with the latest snapshot available in the repository. If needed, it updates the remote repository automatically using `restic_password` as encryption password (see Step 2). In the background, old restic snapshots are removed daily at 01:15 am. Restic also updates itself at 04:15 am if a new binary is available. Finally, the cron daemon is fired up.\n```\nmariadb_1 | [Note] Enabling local and remote backup\nmariadb_1 | [Note] Adding backup cron job\nmariadb_1 | [Note] View the cron logs in '/var/log/mysqldump.log'\nmariadb_1 | [Note] Installed restic 0.9.6 compiled with go1.13.4 on linux/amd64\nmariadb_1 | [Note] Adding restic cron jobs\nmariadb_1 | [Note] View the cron log in '/var/log/restic.log'\nmariadb_1 | [Note] Initialized cron daemon\n```\n\n### Initializing the MariaDB Database\nOnce the backup jobs are scheduled, the MariaDB database is initialized. MariaDB starts as a temporary server, creates the Ghost database schema, and gives the required privileges to the designated `ghost` database user. A user `ghost_backup` is created for the `mysqldump` cron job scheduled in the previous section as well. The actual MariaDB server is started once the initialization is done.\n```\nmariadb_1 | [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.3.22+maria~bionic started.\nmariadb_1 | [Note] [Entrypoint]: Temporary server started.\nmariadb_1 | [Note] [Entrypoint]: Creating database ghost\nmariadb_1 | [Note] [Entrypoint]: Creating user ghost\nmariadb_1 | [Note] [Entrypoint]: Giving user ghost access to schema ghost\nmariadb_1 | [Note] Creating mariadb backup user 'ghost_backup' for database\nmariadb_1 | [Note] [Entrypoint]: MySQL init process done. Ready for start up.\n```\n\n### Starting the MariaDB Database\nWith the database properly initialized, MariaDB can start accepting connections. The default port is `3306`.\n```\nmariadb_1 | [Note] mysqld: ready for connections.\nmariadb_1 | Version: '10.3.22-MariaDB-1:10.3.22+maria~bionic' socket: '/var/run/mysqld/mysqld.sock' port: 3306 [...]\n```\n\n### Initializing Ghost Data\nThe `docker-compose` configuration instructs Ghost to wait for the database to become available on port `3306`. Once the database is available, Ghost will create and populate all tables, models, and relations in the first run.\n```\nghost_1 | docker-compose-wait - Everything's fine, the application can now start!\nghost_1 | INFO Creating table: [...]\nghost_1 | INFO Model: [...]\nghost_1 | INFO Relation: [...]\n```\n\n### Starting the Ghost Server\nOnce the data is available, Ghost will start running in production mode. Typically the initial run takes up to a minute. The boot time is drastically reduced when reconnecting to an existing database. You can now access Ghost at `http://example.test` and set up your (administrative) user(s).\n```\nghost_1 | [2020-06-17 11:45:40] INFO Ghost is running in production...\nghost_1 | [2020-06-17 11:45:40] INFO Your site is now available on http://example.test\nghost_1 | [2020-06-17 11:45:40] INFO Ctrl+C to shut down\nghost_1 | [2020-06-17 11:45:40] INFO Ghost boot 24.849s\n```\n\n### Configuring the Reverse Proxy\nThe reverse proxy maps the public URLs to the local Ghost service. The main blog is available at `example.test`. By default, the `www.example.test` subdomain is redirected to `example.test` too. The subdomain `admin.example.test` redirects to Ghost's admin portal available at `example.test/ghost/`. If the variable `CACHING` is set to `true`, all Ghost content is cached except for the admin portal. The certificates are self-signed by default, which can be changed to trusted certificates by setting `STAGE` to `production`.\n\n```\nportal_1 | [2020-06-24 04:43:20] INFO Enabling caching\nportal_1 | Generating DH parameters, 2048 bit long safe prime, generator 2\nportal_1 | Self-signing test certificate for example.test\nportal_1 | Self-signing test certificate for www.example.test\nportal_1 | Self-signing test certificate for admin.example.test\nportal_1 | [services.d] starting services\nportal_1 | [services.d] done.\n```\n\n\n## Deployment\nThe steps for deploying in production are slightly different than for local testing. Below four steps highlight the changes compared to the testing walkthrough.\n\n\n### Step 1 - Clone the Repository\n*Unchanged*\n\n### Step 2 - Create Docker Secrets\nInstead of file-based secrets, you will now create secure secrets. Docker secrets can be easily created using pipes. Do not forget to include the final `-`, as this instructs Docker to use piped input. Update the credentials as needed.\n\n```console\nprintf password | docker secret create db_root_password -\nprintf ghost | docker secret create db_user -\nprintf password | docker secret create db_password -\nprintf ghost_backup | docker secret create db_backup_user -\nprintf password | docker secret create db_backup_password -\nprintf password | docker secret create restic_password -\nprintf XXX | docker secret create STAGE_B2_ACCOUNT_ID -\nprintf XXX | docker secret create STAGE_B2_ACCOUNT_KEY -\n```\n\nIf you do not feel comfortable copying secrets from your command line, you can use the wrapper `create_secret.sh`. This script prompts for a secret and ensures sensitive data is not displayed in your console. The script is available in the folder `/docker-secret` of your repository.\n\n```console\n./create_secret.sh db_root_password\n./create_secret.sh db_user\n./create_secret.sh db_password\n./create_secret.sh db_backup_user\n./create_secret.sh db_backup_password\n./create_secret.sh restic_password\n./create_secret.sh STAGE_B2_ACCOUNT_ID\n./create_secret.sh STAGE_B2_ACCOUNT_KEY\n```\n\nThe `docker-compose.yml` in the repository defaults to set up for local testing. Update the `secrets` section to use Docker secrets instead of local files.\n\n```Dockerfile\nsecrets:\n db_root_password:\n external: true\n db_user:\n external: true\n db_password:\n external: true\n db_backup_user:\n external: true\n db_backup_password:\n external: true\n restic_password:\n external: true\n STAGE_B2_ACCOUNT_ID:\n external: true\n STAGE_B2_ACCOUNT_KEY:\n external: true\n```\n\n### Step 3 - Update the Environment Variables\n*Unchanged, however, update DOMAINS_BLOG, DOMAINS_ADMIN, and set TARGET to production once everything is working properly*\n\n### Step 4 - Run the Docker Service\nThe Docker services will be deployed to a Docker Stack in production. Unlike Docker Compose, Docker Stack does not automatically create local folders. Create empty folders for the `mariadb`, `ghost`, and `portal` data. Next, deploy the Docker Stack using `docker-compose` as input. This ensures the environment variables are parsed correctly.\n\n\n```console\nmkdir -p data/mariadb/mysql\nmkdir -p data/mariadb/backup\nmkdir -p data/mariadb/log\nmkdir -p data/ghost\nmkdir -p data/portal\ndocker-compose config | docker stack deploy -c - ghost-backend\n```\n\nRun the following command to inspect the status of the Docker Stack.\n\n```console\ndocker stack services ghost-backend\n```\n\nYou should see the value `1/1` for `REPLICAS` for the `mariadb`, `ghost`, and `portal` services if the stack was initialized correctly. It might take a while before the services are up and running, so simply repeat the command after a few minutes if needed.\n\n```\nID NAME MODE REPLICAS IMAGE PORTS\n*** ghost-backend_mariadb replicated 1/1 markdumay/mariadb:latest \n*** ghost-backend_ghost replicated 1/1 markdumay/ghost:latest *:2368->2368/tcp\n*** ghost-backend_portal replicated 1/1 markdumay/portal:latest *:80->80/tcp, *:443->443/tcp\n```\n\nYou can view the service log with `docker service logs ` once the service is up and running. Refer to Step 4 for validation of the logs.\n\nDebugging swarm services can be quite challenging. If for some reason your service does not initiate properly, you can get its task ID with `docker service ps `. Running `docker inspect ` might give you some clues to what is happening. Use `docker stack rm ghost-backend` to remove the docker stack entirely.\n\n## Usage\n\n### Setting Up a Ghost Administrator\nOpen your internet browser and navigate to the Ghost admin page. The default value is `example.test/ghost` or `example.com/ghost` pending you are in test mode or production. The site's certificate is self-signed in a local setup, so you might need to instruct your internet browser to trust this certificate. The site should now display the setup screen of Ghost and will ask you to set up an administrative user. \n\n![Ghost setup screen][image_setup]\n\nOnce you have set up your administrative account and finished configuring Ghost, you can navigate to the main site at either `example.test` or `example.com`. Ghost is now ready for use.\n\n![Ghost home screen][image_home]\n\n### Restoring the Ghost Database\nIf enabled in the environment settings, *Ghost-backend* creates local backups of the database every 30 minutes. See the `BACKUP` setting in Step 3 on how to enable this. Under the hood, the script `mysqldump-local.sh` embedded in the `mariadb` container exports the Ghost data to a file in the `/var/backup/mariadb` folder. The same script can also be used to restore the database. To do so, connect to the shell of your running mariadb container by running below command from your host.\n```\ndocker exec -it ghost-backend_mariadb_1 bash\n```\n\nFrom within the container, run the following command to restore the Ghost database from the latest backup available in `/var/backup/mariadb`. You can replace the backup path with another path if needed.\n\n```\nmysqldump-local.sh restore /var/backup/mariadb\n```\n\nBy default, `mysqldump-local.sh` uses the latest available backup. You can specify a specific file using the `-b` flag.\n\nOnce the operation is confirmed, all existing data of the Ghost database is replaced with the content from the backup file. When completed, the scripts should return below message:\n\n```\nCompleted restore from '/var/backup/mariadb/ghost_backup_YYYYMMDD_HHhMMmSSs.sql' in 2 seconds\n```\n\nYou can now exit the container with the command `exit`. Finally, restart the `ghost` container to ensure Ghost works correctly with the restored data.\n\n\n## Contributing\n1. Clone the repository and create a new branch \n ```\n $ git checkout https://github.com/markdumay/ghost-backend.git -b name_for_new_branch\n ```\n2. Make and test the changes\n3. Submit a Pull Request with a comprehensive description of the changes\n\n## Credits\n*Ghost-backend* is inspired by the following blog article:\n* Scott Helme - [Caching Ghost with Nginx][nginx_cache]\n\n## Donate\n $\"Buy$ \n\n## License\n\n

\n\n\nCopyright © [Mark Dumay][blog]\n\n\n\n\n[Backblaze B2]: https://www.backblaze.com/b2/cloud-storage.html\n[docker_url]: https://docker.com\n[ghost_info]: https://ghost.org/docs/concepts/introduction/\n[ghost_url]: https://ghost.org\n[macos_dnsmasq]: https://www.stevenrombauts.be/2018/01/use-dnsmasq-instead-of-etc-hosts/\n[mariadb_url]: https://mariadb.com\n[mysqldump]: https://mariadb.com/kb/en/mysqldump/\n[nginx_cache]: https://scotthelme.co.uk/caching-ghost-with-nginx/\n[portal_url]: https://github.com/SteveLTN/https-portal\n[restic_integration]: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html\n[restic_url]: https://restic.net\n\n\n\n[blog]: https://github.com/markdumay\n[repository]: https://github.com/markdumay/ghost-backend.git\n[ubuntu-docker]: https://github.com/markdumay/ubuntu-docker\n\n\n[image_setup]: https://github.com/markdumay/ghost-backend/raw/master/images/ghost-setup.png\n[image_home]: https://github.com/markdumay/ghost-backend/raw/master/images/ghost-home.png","has_starred","hub_user","immutable_tags_settings",{"_70":11,"_71":72},"enabled","rules",[73],".*","is_automated","permissions",{"_77":17,"_78":11,"_79":11},"read","write","admin","user","storage_size",493819169,"orgData","recentTags",[86],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":95,"_45":112,"_113":89,"_114":28,"_115":51,"_52":116,"_117":118,"_119":103,"_120":112,"_121":61,"_122":17},"content_type","creator",9595884,"full_size",116051705,"id",106092313,"images",[96],{"_97":98,"_99":100,"_101":43,"_102":103,"_104":105,"_106":107,"_108":43,"_109":-5,"_110":91,"_58":61,"_111":-5},"architecture","amd64","digest","sha256:6920aa1c9df6c548f223e878e83b4dce391cd252f9b1449a0704eb36cc55e758","features","last_pulled","2026-09-15T17:38:00.302064005Z","last_pushed","2020-10-29T15:25:53Z","os","linux","os_features","os_version","size","variant","2020-10-29T15:25:52.188757Z","last_updater","last_updater_username","media_type","latest","repository",9320182,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_33":132,"_139":140,"_128":149,"_150":11},{"_35":133,"_37":134,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":135,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":136,"_74":11,"_75":138,"_80":28,"_81":82},[],[39],[51],{"_70":11,"_71":137},[73],{"_77":17,"_78":11,"_79":11},"tags",{"_141":59,"_142":-5,"_143":-5,"_144":145},"count","next","previous","results",[146],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":147,"_45":112,"_113":89,"_114":28,"_115":51,"_52":116,"_117":118,"_119":103,"_120":112,"_121":61,"_122":17},[148],{"_97":98,"_99":100,"_101":43,"_102":103,"_104":105,"_106":107,"_108":43,"_109":-5,"_110":91,"_58":61,"_111":-5},[],"canDeleteTags","actionData","errors"]

markdumay/ghost

Tags for markdumay/ghost