Ghost in A shell - part II : HTTPs is the norm
Tags: ghost, productivity, docker, tutorial
Published: 2018-05-25 20:46:11

---
title: Ghost in A shell - part II : HTTPs is the norm
published: true
tags: ghost,productivity,docker,tutorial
canonical_url: https://manu.breton.ch/blog/deploying-ghost-part2-https-domain/
---

 ![Ghost in A shell - part II : HTTPs is the norm](https://manu.breton.ch/blog/content/images/2018/05/image-blog-2-3.png)

Overview of the context in three points:

- The objective of this series is to facilitate (automate) the spawning of Ghost blogs
- This blog comes after [part I - localhost](https://dev.to/ebreton/ghost-in-a-shell---part-i--localhost-5he9), where I focused on one's computer
- The targeted audience are developers/ops who wish to build / wipe out ghost instances in a breeze

Would you be interested, please take a seat and make yourself at home, I will try 1) to make your reading comfortable, 2) to lead you to the magic world where Ghosts appear from thin air... and 3) to give you the magic wand that will pop out:

- [https://my.domain.com/ghost-local](https://my.domain.com/ghost-local)
- [https://my.domain.com/another-ghost](https://my.domain.com/another-ghost)
- [https://my.domain.com/name-it](https://my.domain.com/name-it)

# Appetizer: the repo(s)

In order to fulfil my promises, I will make use of two repositories:

1. [prod-stack](https://github.com/ebreton/prod-stack), which I have already introduced in the first blog. This repo will act as router and proxy for free, including the discussions with Let's Encrypt
2. [ghost-in-a-shell](https://github.com/ebreton/ghost-in-a-shell), which basically is the material behind the blogs.

By cloning those two guys, and setup a few variables, you will be able to create your ghost instances with our old pal `make`

## Quick setup for prod-stack

Just to save you a return ticket to the [first blog](https://dev.to/ebreton/ghost-in-a-shell---part-i--localhost-5he9), here are the few steps necessary to get the _prod-stack_ up and serving:

```
$ git clone git@github.com:ebreton/prod-stack.git
Cloning into 'prod-stack'...
...
$ cd prod-stack
$ make
cp etc/traefik.toml.sample etc/traefik.toml
cp etc/db.sample.env etc/db.env
sed -i s/password/auMr9jsMrPnX0Oatb9j4yX2AYBN2jTQV/g etc/db.env
Generated etc/db.env
docker-compose pull
Pulling nginx-entrypoint ...
...

```

Once the logs stabilize, you can `Ctrl-C` to get back on the command line, and `docker ps` to check that the stack is running.

The Traefik dashboard will be available on [http://localhost:8081](http://localhost:8081) "protected" by Basic Authentication with the user _test/test_

## Quick setup for ghost-in-a-shell

Well, you should have _make_, _docker_ and the _prod-stack_ installed at this point.

You are ready to spawn a blog on [http://localhost:3001](http://localhost:3001) with `make`, or on [http://localhost/ghost-local](http://localhost/ghost-local) with `make traefik`.

Let's see how to do better!

> from here on, running a container with `make` will be called the **standalone mode**. Running a container with `make traefik` will be called the **traefik mode** (how original!)

# Starters: environment variables

The two modes make use of environment variables, with default values defined in the (well commented) [_.env_](https://github.com/ebreton/ghost-in-a-shell/blob/master/.env) file.

If you happen to delete this file, `make` will complain

```
$ rm .env
$ make
.env file is missing
make: *** [check-env] Error 1

```

If _.env_ is found, you will be able to check its values with `make vars`

```
$ make vars
# values that will be used to create the blog URL
  NAME=ghost-local
  PROTOCOL=http
  DOMAIN=localhost
  PORT=3001
  URI=ghost-local

```

Changing the configuration of the instance is a matter of changing those variables:

- either directly in the _.env_ file
- or in your environment, e.g. adding `export NAME=blog` in your terminal (or in your _.bashrc_ when it comes to some other variables that will vary less in time, e.g _PROTOCOL_)
- or in the command line, e.g. `PORT=3002 make`

```
$ export NAME=blog
$ PORT=3002 make vars
# values that will be used to create the blog URL
  NAME=blog
  PROTOCOL=http
  DOMAIN=localhost
  PORT=3002
  URI=ghost-local

```

The variables should be self explanatory, especially if you think _PROTOCOL://DOMAIN:PORT/URI_, but it never hurts to spell the words, so here is a quick summary of the variables, with their default values and which mode uses them

| Variable | Description | default value | used by standalone / traefik mode |
| --- | --- | --- | --- |
| `NAME` | for the docker container and the data folder | ghost-local | both |
| `PROTOCOL` | to build the URL | http | traefik |
| `DOMAIN` | to build the URL | localhost | both |
| `PORT` | to build the URL | 3001 | standalone |
| `URI` | to build the URL | ${NAME} | traefik |

# The Main Dish: HTTPs

So here we are, we wish to run an instance on [http://my.domain.com/my-blog](http://my.domain.com/my-blog)

I guess the following command is not going to be too much of a shock for you:  
`DOMAIN=my.domain.com URI=my-blog make traefik`

You might actually have jumped straight to [http**S**://my.domain.com/my-blog](https://my.domain.com/my-blog) with `PROTOCOL=https DOMAIN=my.domain.com URI=my-blog make traefik`

That's fine, if you had also anticipated

- The DNS configuration, i.e my.domain.com is already pointing to your server
- The traefik configuration, and in particular if you have setup your own email address in the _traefik.toml_ file as directed in prod-stack/[README](https://github.com/ebreton/prod-stack/blob/master/README.md).

> By the way, do not forget to change the Basic Authentication used to access Traefik dashboard (also pointed out in prod-stack/[README](https://github.com/ebreton/prod-stack/blob/master/README.md))

In this case, you could actually `export PROTOCOL=https` and `export DOMAIN=my.domain.com` in your environment, and simply run `URI=my-other-blog make traefik`.

If you hadn't anticipated... well... you now know what to do :

1. Set DNS config at your preferred provider
2. Adapt Traefik config in prod-stack
3. Ease your process by adding some variables to your environment

As a bonus, you can also force the redirection of http to http**s** (and raw _domain.com_ to _www.domain.com_ as an extra bonus). This is done by Nginx, and through the [configuration sample](https://github.com/ebreton/prod-stack/blob/master/etc/002-redirect-to-https.conf.sample) in the repo, which you just have to move to the _./etc/conf.d_ folder, and then restart the stack

```
$ cd /path/to/prod-stack
$ mv ./etc 002-redirect-to-https.conf.sample ./etc/conf.d/002-redirect-to-https.conf
$ make
...

```

Doing all of this will

- redirect [http://domain.com/blog](http://domain.com/blog) to [https://www.domain.com/blog](https://www.domain.com/blog) (which go well beyond our initial objectives, but hey! that's nice and free, and optional)
- get a certificate from Let's Encrypt for www.domain.com
- serve the blog

But there is more...

# Digestive: helpers

We have already used `make vars` that listed the values of the environment variables.

There is a few other helpers command, which are listed in the table below:

| Command | Description | Variables used |
| --- | --- | --- |
| `make vars` | Display the values of all env vars | All |
| `make ps` | Display the running containers | None |
| `make shell` | Connect to given Ghost container | NAME |
| `make logs` | Tail and follow the logs of given Ghost container | NAME |
| `make stop` | Stop given Ghost container | NAME |

There is really few to say here, they are just convenient wrappers around standard docker commands.

# Dessert (conclusion)

I must admit that I am quite satisfied with the outcome of this second blog.

We just have one tiny little bit of work to cope with now: the technical debt !

More seriously, the choices made so far are shortcuts for most of them.

- Ghost is running in development mode,
- and still uses _sqlite_.
- Not to mention there is no monitoring neither backup of anything (by the way, do not forget that you have [Ghost(Pro)](https://ghost.org/features/) to relieve you from those burdens).

It is therefore a very appropriate time for a very big red disclaimer:

> do NOT use this stack in production

# Next?

I will look more deeply into Ghost setup in next blog: its running mode and the DB to start with...