Selaa lähdekoodia

grammer fixes

master
Cian Butler 3 vuotta sitten
vanhempi
commit
31a670c3e6
Signed by untrusted user: butlerx GPG Key ID: B37CA765BAA89170
3 muutettua tiedostoa jossa 33 lisäystä ja 38 poistoa
  1. +0
    -6
      .gitignore
  2. +1
    -0
      config.toml
  3. +32
    -32
      content/post/2018-04-02.md

+ 0
- 6
.gitignore Näytä tiedosto

@@ -1,6 +1,3 @@

# Created by https://www.gitignore.io/api/vim,hugo,emacs,visualstudio

### Emacs ###
# -*- mode: gitignore; -*-
*~
@@ -375,6 +372,3 @@ __pycache__/
### VisualStudio Patch ###
# By default, sensitive information, such as encrypted password
# should be stored in the .pubxml.user file.


# End of https://www.gitignore.io/api/vim,hugo,emacs,visualstudio

+ 1
- 0
config.toml Näytä tiedosto

@@ -3,6 +3,7 @@ languageCode = "en-us"
title = "Redbrick Admin Blog"
author = "Redbrick Admin"
pygmentsCodeFences = true

[outputs]
home = ["HTML", "RSS", "JSON"]



+ 32
- 32
content/post/2018-04-02.md Näytä tiedosto

@@ -4,39 +4,39 @@ date: 2018-04-02T21:11:41+01:00
author: butlerx
tags:
- Docker
- Postgres
- PostgrSQL
---

# Why you need to lock versions

## The Preamble

Redbrick runs a service called [Hackmd](https://md.redbrick.dcu.ie). It is web
based markdown editor. At the start of the year Hackmd version one came out and
in early February we decided to update it.
Redbrick runs a service called [HackMD](https://md.redbrick.dcu.ie). It is
web-based markdown editor. At the start of the year HackMD version one came out
and in early February we decided to update it.

Unlike most updates in Redbrick this isn't really a big thing as it runs inside
Docker container, with its only external dependency being Postgres 9. We don't
actually have a central a central Postgres database in Redbrick, a problem for
another day, just a mysql. So inside another container we run Postgres.
Unlike most updates in Redbrick, this isn't really a big thing as it runs inside
Docker container, with its only external dependency being PostgreSQL 9. We don't
actually have a central a central PostgreSQL database in Redbrick, a problem for
another day, just a MySQL. So inside another container, we run PostgreSQL.

The update process was meant to be simple update the `Dockerfile`, run
`docker-compose up --build`, and wait....
`docker-compose up --build` and wait...

## What Actually Went Wrong

And we waited but hackmd didn't come back. One tail of the logs later and the
problem was obvious Postgres had restarted. But not only that it was trying and
failing to upgrade itself to postgres 10.
And we waited but HackMD didn't come back. One tail of the logs later and the
problem was obvious PostgreSQL had restarted. But not only that it was trying
and failing to upgrade itself to PostgreSQL 10.

The Problem was Docker had pulled the latest version of postgres. This was fine
when hackmd was first installed the year earlier when all the docker tags
pointed to postgres 9, but wasn't so great after.
The Problem was Docker had pulled the latest version of PostgreSQL. This was
fine when HackMD was first installed the year earlier when all the docker tags
pointed to PostgreSQL 9 but weren't so great after.

## The Fix

The fix was pretty simple add a version tag to for the database image to the
`docker-compose.yml`. A quick `vim` and `docker-compose up` later and hackmd was
The fix was pretty simple to add a version tag to for the database image to the
`docker-compose.yml`. A quick `vim` and `docker-compose up` later and HackMD was
back with lots of new bells and whistles.

So we went through and changed all the other compose files to have tagged
@@ -46,26 +46,26 @@ Problem Solved. Clean our hands and move on. Well unfortunately not.

## The Solution

Over the next couple of months couple problems were mentioned with hackmd but no
one really looked in to them. That was until it affected an admin. We couldn't
Over the next couple of months, a couple problems were mentioned with HackMD but
no one really looked into them. That was until it affected an admin. We couldn't
publish our roadmap for in coming admins.

So back to the logs and yep database issue. Seems that Postgres cant find some
of the keys. Initial thought was that we missed a database migration way back
when we upgraded. So we execed in to the container ran the migrations script and
.... nothing, there wasn't any.
So back to the logs and yep database issue. Seems that PostgreSQL cant find some
of the keys. An initial thought was that we missed a database migration way back
when we upgraded. So we `exec`ed into the container ran the migrations script
and ...nothing, there wasn't any.

Back to the drawing board. We start reviewing configs and double checking
against the repo. But everything seems right. Next we decide to go to the heart
of the problem the database itself. One docker run and we have a postgresql
shell. Start digging though tables, trying to find the missing key when we get a
duplicate key error and an alias.
against the repo. But everything seems right. Next, we decide to go to the heart
of the problem the database itself. One docker run and we have a PostgreSQL
shell. Start digging through tables, trying to find the missing key when we get
a duplicate key error and an alias.

BINGO

Odd thing was when you looked up the alias there was only one entry for it. We
couldn't delete the duplicate entry as it didn't exist and couldn't modify the
table entries as we got duplicate key errors.
The odd thing was when you looked up the alias there was only one entry for it.
We couldn't delete the duplicate entry as it didn't exist and couldn't modify
the table entries as we got duplicate key errors.

Bit of googling later and we had a solution. Copy the table, delete it and
restore. Is this the Database version of turn it off and on again?
@@ -82,11 +82,11 @@ REINDEX
hackmd=# VACUUM(FULL, ANALYZE, VERBOSE);
```

What it turns out is the tables index was wrong. While Postgres' attempt to
What it turns out is the table's index was wrong. While PostgreSQL's attempt to
update itself to 10 had failed it had modified the indexes for some of the
tables and reverting the container didn't magically fix the database inside.

So the tl;dr.
So the TL;DR.

* Always lock your container version
* containers don't magically fix things


Ladataan…
Peruuta
Tallenna