Towards a v1 version of discourse docker image

feature
,
1

As we march towards v1 I would like us to tighten up our base docker image for release.

Issues I would like to see addressed:

  1. Sane/comprehensive logging strategy.
  2. Review of cron jobs.
  3. Update all software, add missing stuff.
  4. Document the base image

Comprehensive logging strategy

Logging is a bit all-over-the-place, some stuff shows up in ./launcher logs , some stuff is trapped in /var/logs. We need to have sane simple logging story. Log rotation should be running, logs should be pulled out of container in sample configs so you don’t lose a pile of logs on re-bootstrap.

Review of cron jobs

What cron jobs do we need to run? Does it make sense to even backup discourse seeing it is built in?

Update all software, add missing stuff.

For v1 we should be on latest ruby 2.0, NGINX should be updated, PG updated to latest stable, OS packages updated. I always trip on VIM missing, I think we should add it.

Anything else?

###Document the base image

Explain what the base image is, what it has and how its configured somewhere. Even as a meta topic.

@supermathie feedbacks? anything missing? Ideally you can take this one.

Also, we should review @honglilai’s https://github.com/phusion/baseimage-docker to see if we want to borrow any concepts.

6 Likes
2

This. :thumbsup: +9000

3 
volumes:
  - volume:
      host: /var/docker/shared/app/rails-log
      guest: /shared/log/rails
  - volume:
      host: /var/docker/shared/app/var-log
      guest: /var/log
  - volume:
      host: /var/docker/shared/app/uploads
      guest: /shared/uploads
  - volume:
      host: /var/docker/shared/app/backups
      guest: /shared/backups

This lets us pull all of the state right out of the container and leave it on the host filesystem. Log rotation can then also be done from the host or the guest as we decide. The only slightly weird thing is the /shared/log/rails mount - it’s there due to the symlinks in the app dir:

- ln -s /shared/log/rails $home/log
- ln -s /shared/uploads $home/public/uploads
- ln -s /shared/backups $home/public/backups

but I’d rather have it slightly weird there than worry about breaking any existing installs.

So… how do we tell unicorn to rotate logfiles?

1 Like
4

Would it be possible to move the container management scripts (i.e. discourse_docker) out of /var/docker? That location is wrong on so many levels…

2 Likes
5

This is not trivial to change to say the least.

I wanted all Discourse Docker stuff under one roof and /var/docker seemed like the best compromise.

We could put ./launcher in /usr or /opt configuration in /etc and data in /var but it becomes hard to get a handle of things.

I really like that I can go to any system and just look at /var/docker to get a handle on things despite it not being an “ideal” structure.

6

I much prefer not adding a gazzilion volumes and just keeping shared and going the symlink route.

We should do all log rotation with logrotate in a cron job. Also we should log runits stuff into /logs as opposed to piping it to docker logs which is hard to find and consume.

7

I also prefer one roof to rule them all approach.

I don’t know why but at first I expected having
/var/discourse/ rather the /var/docker

but I got used to it by now… so no complains.

1 Like
8

We certainly do - I’ve pulled one in and I’m sure there’s more we can “borrow” :smiley:

9

I concur. I personally installed everything under /var/docker-discourse because I was afraid of overwriting anything important in /var/docker (other containers are used on the same server).

I never ran into trouble so far, but I’m not using evry single configuration option, so I might be in for some surprises…

2 Likes
10

Well, if you wanted to follow the POSIX norm…

  • launcher should be called discoursectl and live in /usr/bin,
  • templates, containers, scripts and samples go into /usr/share/discourse,
  • app.yml and any others go into /etc/discourse,
  • and the variable data files belong into /var/lib/discourse.

At least if discourse_docker is installed via package manager. For manual installation, put the launcher and static stuff into /usr/local/discourse.

Then again… I’m still not even using Docker. :laughing:

11

I kind of agree with this @sam. I like Docker fine but where is OUR branding in that path? Docker could be anything, it is just a container…

1 Like
12

I don’t mind changing this to /var/discourse really its just a documentation update … nothing else is needed

1 Like
13

We should make that change before V1 otherwise we are stuck with generic container name path forever.

2 Likes
14

Is this all complete, can this be closed?

15

Yes pretty much, closing