Installation sur Kubernetes

Soutien Installation
21

Yes

Whatever ENV you specify when you finally do you docker run on the image … will take.

22

And doing those things at every boot of the container is reasonable?

23

Some people like this pattern, I do not, that is why rails introduces some super fancy locking around migrations to ensure they never run concurrently when a cluster of 20 app try to run migrations at the same time.

Some people just boot the same image and run the migrations in some out-of-band process.

24

But each container should still rake assets:precompile at least once?

25

Depends on how do you host those.

If you have a NFS share of some sort (like AWS EFS) or if you upload those to some object storage service that can only be done on bootstrap.

26

Merci à tous pour toutes ces réponses utiles. J’ai encore quelques questions sur la manière de procéder correctement.

J’essaie de préparer un fichier app.yaml minimal pour l’amorçage, ne contenant que les informations requises pour la construction du conteneur. Certaines des informations qu’il contient sont clairement destinées à l’exécution du conteneur, comme les montages de volumes et les mappages de ports. Mais je ne suis pas sûr pour les variables d’environnement. Je suppose que je vais simplement essayer, mais ces variables d’environnement sont-elles utilisées lors de la construction du conteneur (injectées dans le Dockerfile d’une manière ou d’une autre) ou uniquement au moment de l’exécution du conteneur ? Si c’est le cas, je m’assurerai qu’elles se retrouvent dans le fichier de configuration k8s approprié.

Deuxièmement, certaines personnes ici ont parlé de pousser l’image vers un référentiel de conteneurs privé. Est-ce obligatoire ? Autrement dit, l’image de construction contient-elle des informations secrètes qui ne devraient pas être publiées sur un référentiel public comme Docker Hub ? (Nous n’avons pas encore de référentiel de conteneurs privé et j’aimerais éviter d’en configurer un.)

Enfin, existe-t-il un paramètre app.yaml pour contrôler le nom du conteneur créé ? C’est plutôt une question de finition, mais ce serait agréable :slight_smile:.

Merci d’avance pour votre aide ! (Désolé de faire remonter un ancien fil. C’est le premier résultat sur Google lors de la recherche sur la façon d’installer Discourse sur Kubernetes.)

27

@Geoffrey_Challen Vous pouvez créer une image avec le dépôt Discourse et les plugins, installer les gems Ruby et autres dépendances, puis la pousser vers un registre (comme DockerHub). Ce dépôt serait agnostique à l’environnement et pourrait être public (sauf si vous incluez un plugin privé ou autre chose de ce genre). Cette image de base pourrait être utilisée dans des environnements de staging et de production, voire dans différents projets (s’ils utilisent les mêmes plugins).

Des étapes comme la précompilation des assets, la migration de la base de données et la génération du certificat SSL doivent toutefois être exécutées sur la machine cible pour générer l’image finale.

Je ne sais pas exactement comment intégrer cela dans un cluster k8s. J’ai opté pour une approche conservatrice en suivant le guide officiel de l’équipe Discourse, en séparant simplement le processus en deux étapes.

28

Cette partie, je ne suis pas sûr de bien la comprendre. Ces opérations ne se produisent-elles pas automatiquement à l’intérieur du conteneur au besoin ? J’espère pouvoir simplement pousser cela dans notre cloud sans jamais avoir besoin d’accéder au shell de la machine, un peu comme je n’ai rarement (voire jamais) besoin d’entrer dans le conteneur Docker de Discourse.

29

Vous n’avez pas besoin de spécifier explicitement le conteneur. Ce que je veux dire, c’est que vous ne pouvez pas générer une image précompilée avec eux (générée dans un pipeline CI, par exemple) et l’utiliser telle quelle, car cela doit être exécuté sur la machine cible, où se trouve la base de données (cela pourrait être automatisé, mais je ne l’ai pas fait dans k8s, bien que je l’aie fait avec Ansible).

30

Ah, d’accord. J’utilise les modèles tout-en-un pour inclure la base de données dans le conteneur. Cela convient à notre cas d’usage, qui implique des classes de 10 à 1000 étudiants. Du moins, le modèle tout-en-un a bien fonctionné pour ma classe dans cette configuration. Donc la base de données est à l’intérieur du conteneur.

Mais peu importe, Discourse ne lance-t-il pas les migrations de base de données ou d’autres étapes de configuration au démarrage du conteneur ?

31

Êtes-vous certain que la base de données se trouve à l’intérieur du conteneur ? Ou s’agit-il du SGBD (dans ce cas, PostgreSQL) ? L’installation prise en charge utilise une base de données externe au conteneur (ce qui est attendu), en mappant un volume interne vers l’extérieur (l’hôte). De plus, après une reconstruction du conteneur, celui-ci est recréé et vous perdriez toutes les données.

Si la base de données est vraiment à l’intérieur du conteneur, je ne sais pas exactement comment vous pourriez procéder à une mise à niveau basée sur l’installation officielle, car le script launcher semble créer et détruire le conteneur plusieurs fois lors de la reconstruction (et s’exécute avec --rm, ce qui signifie que vous perdriez toutes vos données, y compris la base de données, après l’arrêt du conteneur).

Je n’ai pas essayé de modifier la façon dont la reconstruction est effectuée, mais en supposant que vous puissiez la modifier pour exécuter tout à l’intérieur du conteneur sans le recréer, vous devriez pouvoir pousser le conteneur vers un registre (assurez-vous qu’il est privé, car les secrets s’y trouveraient). Cela dit, je ne recommande pas cette approche pour plusieurs raisons (certaines mentionnées précédemment).

32

L’installation standard inclut nginx, Rails, PostgreSQL et Redis à l’intérieur du conteneur. Elle utilise des volumes externes pour les données de PostgreSQL et Redis. Ces volumes ne sont pas supprimés lors d’une reconstruction ou d’une mise à niveau.

33

Oui, c’est juste étrange qu’il ait dit que la base de données se trouve à l’intérieur du conteneur, sauf s’il a changé la façon dont l’installation standard fonctionne, ou s’il voulait dire PostgreSQL, et non la base de données elle-même.

34

Non - les étapes de migrations et de compilation des assets se déroulent pendant la phase ./launcher bootstrap, après la résolution des plugins. Une fois cela terminé, le conteneur peut être redémarré autant de fois que nécessaire, ou les processus web peuvent être répartis sur plusieurs machines, etc.

En imaginant la configuration, cela devrait ressembler à ceci :

  • les versions officielles fournissent déjà l’image de base de Discourse.
    • nous aurons également besoin d’un conteneur pour discourse_docker qui inclut son propre Docker
  • établir un registre privé à l’intérieur du cluster
  • établir un ConfigMap contenant le contenu de app.yml
  • exécuter un Job qui lance ./launcher bootstrap en utilisant le Docker imbriqué sur un nœud basé sur une VM (sans accès au socket Docker), puis renomme et pousse l’image résultante vers le registre privé (avec un libellé basé sur un horodatage, et non latest) (local_discourse n’est pas un bon nom ici) et met à jour le déploiement vers le nouveau libellé
    • wow, c’est beaucoup de permissions pour le job de mise à niveau.
35

Postgres s’exécute à l’intérieur du conteneur. Il enregistre les données en dehors du conteneur, mais il s’exécute à l’intérieur si vous utilisez le jeu standard de modèles d’installation. Idem pour Redis. Je pense que la confusion vient du fait que quand je dis « la base de données s’exécute dans le conteneur », je parle du serveur de base de données, même si les fichiers de la base de données sont stockés en dehors du conteneur. (Mais les fichiers de la base de données ne « s’exécutent » pas, c’est pourquoi je considère ma formulation claire — mais apparemment pas assez claire :slight_smile:.)

PS : en fait, il n’enregistre pas nécessairement les données en dehors du conteneur, sauf si vous configurez Docker pour monter en liaison ce répertoire. J’ai pu sauter cette étape lors du bootstrap, bien que ce ne soit probablement pas une bonne idée, car dans ce cas, le contenu de la base de données ne survivra pas aux redémarrages du conteneur.

36

Je pense que cela commence à avoir plus de sens pour moi maintenant, surtout après avoir lu la longue conversation liée concernant docker-compose, le script de lancement, etc.

Voici ce que je souhaiterais pouvoir faire :

  • Exécuter ./launcher bootstrap localement pour créer une image Discourse « complète » incluant toutes les dépendances : postgres, redis, etc.
  • Déployer cette image sur Kubernetes
  • Plus tard, relancer ./launcher bootstrap pour mettre à jour l’image et redéployer sans détruire les données (évidemment)

Ma compréhension est que l’image Discourse complète ne devrait nécessiter aucune dépendance de service externe. Cependant, pour que les données survivent aux mises à jour des conteneurs, les fichiers de la base de données postgres doivent être stockés en dehors du conteneur. Ce n’est pas un problème — je peux créer un volume persistant k8s pour eux.

Voici maintenant le seul problème que j’anticipe. La plupart des opérations lors de ./launcher bootstrap ne touchent que des fichiers situés à l’intérieur du conteneur. Par exemple, la précompilation des assets. Ce n’est pas grave, car les résultats restent dans le conteneur et n’ont pas besoin de survivre aux mises à jour.

La grande exception ici est la migration de la base de données. Cette étape doit avoir accès à la base de données qui sera utilisée après la fin du bootstrap. Donc, pour moi, cela semble être le principal obstacle au déploiement facile d’images Discourse complètes dans le cloud.

J’ai remarqué que @sam a mentionné à plusieurs reprises qu’il redéploie Discourse pour ses clients en utilisant un flux de travail à peu près similaire à celui que j’ai décrit ci-dessus. Mais je soupçonne que la raison pour laquelle cela fonctionne est que leurs images Discourse sont configurées pour utiliser un serveur de base de données (et probablement Redis également) qui s’exécute sur leur cluster — ce qui serait logique pour prendre en charge plusieurs déploiements, mais ce n’est pas tout à fait ce que je veux faire. Cela signifie que le processus de bootstrap peut modifier la base de données de production — ou peut-être que l’étape de migration de la base de données est tout simplement ignorée, car les mises à jour et les migrations de la base de données sont gérées de manière externe. @sam : pourriez-vous confirmer ?

Quoi qu’il en soit, la conclusion pour moi est que je dois trouver un moyen d’exécuter les migrations de la base de données au démarrage du conteneur, et non pendant ./launcher bootstrap. Je suppose qu’à ce stade, une façon de faire serait :

  • Construire localement le conteneur Discourse complet en utilisant ./launcher bootstrap, avec un montage de volume pointant vers une base de données locale vide, puisque cette base de données ne sera pas utilisée plus tard. Cela permettrait de mettre tout en place dans le conteneur, sans pour autant terminer le travail sur postgres.
  • Trouver un moyen d’exécuter l’étape de migration de la base de données sur la base de données de production réelle — peut-être en utilisant un conteneur d’initialisation k8s ?
  • Remplacer l’ancienne image Discourse par la nouvelle
37

Vous pourriez être intéressé par une configuration multi-sites.

Vous rencontrez deux gros problèmes : Discourse n’est pas prêt pour Kubernetes, ce qui nécessite du code personnalisé. De plus, vous entrez dans le domaine où l’équipe de Discourse génère des revenus (hébergement d’un grand nombre de forums), ce qui entraînera une baisse du niveau de support dont vous bénéficiez.

Mon conseil ? Mettez en place une configuration multi-sites avec un ordonnancement statique sur des machines virtuelles, entièrement en dehors de votre cluster. (Ou utilisez un Service de type ExternalName pointant vers la machine virtuelle pour conserver le même Ingress.)

38

OK… I managed to figure out one way of doing this. I’m not 100% happy with it, but it does work and may be appealing to others that are trying a simple single-container fat (includes postgres, redis, etc.) Discourse image deployment to Kubernetes.

My Approach

After examining the bootstrap process it became clear to me that unfortunately it mixes in two different kinds of operations—ones that only affect the underlying container, and others that poke out into the surrounding environment, mainly through the /shared volume mount where the postgres data files live. Rather than trying to tease these steps apart, it seems more sane to just run the bootstrapping steps in the environment where the container is actually going to be deployed.

Unfortunately, launcher bootstrap wants to create a container and use Docker. So running launcher inside another container (for example, in a container running on our cloud) means either tangling with a Docker-in-Docker setup (doable, but not considered best practices) or exposing the underlying Docker daemon. I’m not even sure that that second approach would work, since I think that it would interpret a volume mount against the node’s local filesystem, whereas in our scenario we want to volume mount /shared to a persistent Kubernetes volume. Maybe the Docker-in-Docker route would work, but then you’d also have a weird triple volume mount from inside the nested container into the outer container and from there to the persistent Kubernetes volume. That sounds… unwise.

However, essentially launcher bootstrap creates one large .yml file by processing the templates value in the app.yml and then passes that to the Discourse base image when finishes the bootstrap process. So if we can extract the configuration file we can generate the configuration on any machine and then we only need to figure out how to pass it to a container we start in the cloud.

So as an overview, here are the steps we are going to follow:

  1. Generate the bootstrap configuration using a modified launcher
  2. Pass that to a modified Discourse base image that will perform the bootstrapping (using pups) and then start Discourse

Generating the Bootstrapping Configuration

Here’s the required change to launcher to support a dump command that writes the merged configuration to STDOUT:

run_dump() {
  set_template_info
  echo "$input"
}

(Note that this command is available in our fork of discourse_docker.)

So the first step is to use the new launcher dump command added above to create our bootstrap configuration:

# Substitute whatever your container configuration is called for app
./launcher dump app > bootstrap.yml

Initial Container Creation

Next we need a container that knows to run pups to bootstrap the container before booting via /sbin/boot. I used the following Dockerfile to make a tiny change to the base discourse image:

FROM discourse/base:2.0.20191219-2109
COPY scripts/bootstrap.sh /
CMD bash bootstrap.sh

Where scripts/bootstrap.sh contains:

cd /pups/ && /pups/bin/pups --stdin < /bootstrap/bootstrap.yml && /sbin/boot

I published this as geoffreychallen:discourse_base:2.0.20191219-2109. (Note that you could probably also accomplish the same thing by modifying the boot command of the base Discourse docker image, but I was having a hard time getting that to work with the shell redirection required to get pups to read the configuration file.)

Kubernetes Configuration

Now we need our Kubernetes configuration. Mine looks like this:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: kotlin-forum-pvc
  namespace: ikp
spec:
  storageClassName: rook-ceph-block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 64Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kotlin-forum-deployment
  namespace: ikp
spec:
  replicas: 0
  selector:
    matchLabels:
      app: kotlin-forum
  template:
    metadata:
      labels:
        app: kotlin-forum
    spec:
      volumes:
      - name: kotlin-forum
        persistentVolumeClaim:
          claimName: kotlin-forum-pvc
      - name: bootstrap
        configMap:
          name: kotlin-forum-bootstrap
      containers:
      - name: kotlin-forum
        image: geoffreychallen/discourse_base:2.0.20191219-2109
        imagePullPolicy: Always
        volumeMounts:
        - name: kotlin-forum
          mountPath: /shared/
        - name: bootstrap
          mountPath: /bootstrap/
        ports:
        - containerPort: 80
        env:
        - name: TZ
          value: "America/Chicago"
        - name: LANG
          value: en_US.UTF-8
        - name: RAILS_ENV
          value: production
        - name: UNICORN_WORKERS
          value: "3"
        - name: UNICORN_SIDEKIQS
          value: "1"
        - name: RUBY_GLOBAL_METHOD_CACHE_SIZE
          value: "131072"
        - name: RUBY_GC_HEAP_GROWTH_MAX_SLOTS
          value: "40000"
        - name: RUBY_GC_HEAP_INIT_SLOTS
          value: "400000"
        - name: RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR
          value: "1.5"
        - name: DISCOURSE_DB_SOCKET
          value: /var/run/postgresql
        - name: DISCOURSE_DEFAULT_LOCALE
          value: en
        - name: DISCOURSE_HOSTNAME
          value: kotlin-forum.cs.illinois.edu
        - name: DISCOURSE_DEVELOPER_EMAILS
          value: challen@illinois.edu
        - name: DISCOURSE_SMTP_ADDRESS
          value: outbound-relays.techservices.illinois.edu
        - name: DISCOURSE_SMTP_PORT
          value: "25"
---
apiVersion: v1
kind: Service
metadata:
  name: kotlin-forum
  namespace: ikp
spec:
  type: NodePort
  ports:
  - name: http
    port: 80
    targetPort: 80
  selector:
    app: kotlin-forum
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  namespace: ikp
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  name: kotlin-forum-ingress
spec:
  rules:
  - host: kotlin-forum.cs.illinois.edu
    http:
      paths:
      - backend:
          serviceName: kotlin-forum
          servicePort: 80

Yours will look different. Note that I’m terminating HTTPS upstream, hence the modifications to the Ingress configuration. I also like to put everything in one file, delete pieces that don’t work as I iterate, and then let Kubernetes skip duplicates on the next kubectl create -f. Also note that I set replicas: 0 so that the deployment doesn’t start as soon as its configured. That’s because we have one bit of additional configuration to finish.

I copied the list of environment variables from what I saw being passed to the container by launcher start. I don’t know if all of these are necessary and others may be missing depending on your configuration. YMMV.

Note that we have two volume maps pointing into the container: the first is for postgres, configured as a persistent volume that will survive pod restarts. The second is a configuration mapping created like this:

kubectl create configmap kotlin-forum-bootstrap --from-file=bootstrap.yml=<path/to/bootstrap.yml>

Where kotlin-forum-bootstrap needs to match your Kubernetes configuration and path/to/bootstrap.yml is the path to the bootstrap.yml file we created using launcher dump above.

Once your configmap is in place, you should be able to scale your deployment to one replica and see Discourse booting and running the same bootstrap process that launcher bootstrap would have performed. That takes a few minutes. When that is done, your Discourse installation will boot.

Others Bits of Configuration

A few other notes that I ran on the way to getting this (at least for now) fully configured:

  • Any upstream proxies must forward X-Forwarded headers, including both X-Fowarded-For, X-Forwarded-Proto, X-Forwarded-Port. Not doing so will result in strange authentication errors when trying to use Google login and probably other login providers.
  • Your nginx ingress controller must be configured to pass headers by setting use-forwarded-headers in the global config map. This took me a while to get right, since at least several times I edited the wrong configuration map, and then expected my ingress containers to restart when the configuration map changed. (They didn’t.)

Updating

To update the deployed installation, you regenerate the new bootstrap.yml file, update the config map, and then restart the container (easiest by scaling to 0 and then back to 1 replica).

This does incur a bit of downtime since the bootstrapping happens before the container is built. But this seems inevitable to me in cases where you need to update the configuration and/or change the base image. launcher rebuild is documented as stop; bootstrap; start, meaning that the bootstrap process will still cause downtime even if performed using the launcher script.

Comments

This fat container Discourse deployment pattern would be much easier to support if the launcher script would more cleanly separate (a) bootstrap steps that could be performed offline and only affect the files in the container and (b) bootstrap steps that modify or need access to the database or other state outside the container. The approach described above is a bit frustrating because you do see all kinds of JS uglification, asset minification, and other things that could be done with the previous deployment running… but they are just too mixed in with other things (like database migrations) that can’t be done without access to the database. I briefly thought about creating a container that would only perform the steps in templates/postgres.yml, but then noticed that database migrations were being done by the web template, and thought about plugins, and then just gave up :slight_smile:.

With better separation redeployment for fat containers could work something like this:

  • Build new fat container offline performing all steps internal to the container
  • Publish that container
  • When ready to upgrade, stop the previous container, start the new fat container, and let it finish any steps that need database access. Based on my experimentation those seem faster than some of the other bootstrap steps.

That would result in a bit less downtime. It’s probably not worth the effort for that reason alone, but I can imagine that this might also simplify more complex deployment scenarios involving shared databases or whatever.

39

Cela a plus de sens. C’est ce que j’ai fait en séparant l’étape de démarrage en deux phases. La première peut s’exécuter dans un environnement isolé (comme un pipeline CI) pour générer une image de base avec le dépôt Discourse, les gems et les plugins installés. La deuxième étape doit s’exécuter sur la machine cible (ou au moins avoir accès à la base de données de production) pour effectuer la migration de la base de données et générer les ressources (cela est fait lors du processus de démarrage, et non au lancement du conteneur).

Oui, ce serait formidable. Je l’ai déjà demandé, mais je ne sais pas si et quand cela sera réalisé.

Ce serait difficile à implémenter complètement dans un environnement séparé car la tâche de précompilation des ressources nécessite un accès à la base de données (pour des éléments comme le CSS personnalisé), mais ce serait idéal si seules les parties dépendant de la base de données pouvaient être traitées dans une étape séparée (et que toutes les autres ressources, qui ne dépendent pas de la base de données, puissent être précompilées séparément, bien que je ne sache pas dans quelle mesure cela serait techniquement réalisable).

40

C’est à peu près ce que je fais sur les installations Kubernetes que j’ai réalisées. Je ne vois pas comment ni pourquoi utiliser k8s sans conteneurs de données et de web séparés (ou une autre forme de PostgreSQL et Redis externes — les installations que j’ai effectuées pour des clients utilisent des ressources GCP pour cela).

De plus, il existe une variable d’environnement skip_post_migration_updates qu’il faut comprendre pour des mises à jour réellement sans temps d’arrêt. Elle est décrite ici.