Una conversazione laterale con @rosscdh ha rivelato che il suo obiettivo principale è Discourse su Kubernetes. Questa non è una configurazione supportata qui. Esistono critiche valide sul modo in cui gestiamo le cose in relazione a Docker/Kubernetes; tuttavia, abbiamo scelto di adottare questo approccio con launcher per facilitarne l’uso nel mondo dell’hosting autonomo.
Ho riaperto questo argomento, ma vi chiedo di mantenere un tono civile e costruttivo.
Ma non esisteva fino a dopo che è stato sviluppato ./launcher. 
Se vuoi lanciare su k8s o simili, quello che faccio è usare il launcher per costruire l’immagine, spingerla da qualche parte e poi far sì che k8s lancia quell’immagine. Il launcher fa alcune cose, come migrare il database durante gli aggiornamenti, quindi devi prestare attenzione a come funziona.
Grazie mille,
L’obiettivo è renderlo più simile a Docker, in modo che possa essere eseguito sia su Kubernetes che con Docker utilizzando container standalone.
Sono riuscito a utilizzare il launcher e a generare un’immagine di oltre 2 GB (4 plugin; non riesco a farne 6 a causa dei limiti).
Ho anche creato un docker-compose, così ora ho un runbook pulito.
Conosco GlobalSettings e ho modificato leggermente application.rb e routes.rb, limitandomi a montare le personalizzazioni.
version: '3'
networks:
discourse-net:
services:
mailhog:
image: mailhog/mailhog:latest
networks:
- discourse-net
ports:
- 8025:8025
postgres:
image: postgres:9.6
networks:
- discourse-net
environment:
POSTGRES_PASSWORD: password
POSTGRES_USER: discourse
POSTGRES_DB: discourse
redis:
image: redis:alpine
networks:
- discourse-net
discourse:
image: discourse-monkey:latest
working_dir: /var/www/discourse
command: bash /var/www/discourse/entrypoint.sh
# ports:
# - 3000:3000 # usa l'entrypoint di nginx
networks:
- discourse-net
volumes:
- ./entrypoint.sh:/var/www/discourse/entrypoint.sh
- ./config/unicorn.rb:/var/www/discourse/config/unicorn.rb
- ./config/application.rb:/var/www/discourse/config/application.rb
- ./envs/production.rb:/var/www/discourse/config/environments/production.rb
- ./overrides/routes.rb:/var/www/discourse/config/routes.rb
- ./generated/public/assets:/var/www/discourse/public/assets
- ./generated/public/images:/var/www/discourse/public/images
- ./generated/public/uploads:/var/www/discourse/public/uploads
- ./generated/public/javascripts:/var/www/discourse/public/javascripts
- ./generated/public/svg-sprite:/var/www/discourse/public/svg-sprite
environment:
LANG: en_US.UTF-8
DISCOURSE_DEFAULT_LOCALE: en
RAILS_ENV: production
## Quanti richieste web concorrenti sono supportati? Dipende dalla memoria e dai core della CPU.
## verrà impostato automaticamente da bootstrap in base alle CPU rilevate, oppure puoi sovrascriverlo
UNICORN_WORKERS: 3
## TODO: Il nome di dominio a cui risponderà questa istanza di Discourse
DISCOURSE_HOSTNAME: discuss.monkey.tech:3001
DOCKER_USE_HOSTNAME: "true"
## Rimuovi il commento se vuoi che il container venga avviato con lo stesso
## nome di host (-h option) specificato sopra (default "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: Elenco di email separate da virgola che diventeranno amministratori e sviluppatori
## alla prima registrazione, esempio 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'me@example.com,you@example.com'
## TODO: Il server SMTP utilizzato per validare nuovi account e inviare notifiche
## Sono richiesti indirizzo, nome utente e password SMTP
## ATTENZIONE: il carattere '#' nella password SMTP può causare problemi!
DISCOURSE_SMTP_ADDRESS: mailhog
#DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: mailhog
DISCOURSE_SMTP_PASSWORD: password
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (opzionale, default true)
## Se hai aggiunto il template di Lets Encrypt, rimuovi il commento qui sotto per ottenere un certificato SSL gratuito
#LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## TODO: configura la connettività ai database
# DISCOURSE_DB_SOCKET: ''
DISCOURSE_DB_HOST: postgres
DISCOURSE_DB_USERNAME: discourse
DISCOURSE_DB_PASSWORD: password
DISCOURSE_REDIS_HOST: redis
## L'indirizzo CDN http o https per questa istanza di Discourse (configurato per il recupero)
## vedi https://meta.discourse.org/t/14857 per i dettagli
DISCOURSE_CDN_URL: http://discuss.monkey.tech:3001
DISCOURSE_SERVE_STATIC_ASSETS: "true"
SKIP_ENFORCE_HOSTNAME: '0'
ENABLE_ASSETS_PIPELINE: '0'
ENABLE_DB_MIGRATE: '0'
DISCOURSE_ENABLE_CORS: 'false'
DISCOURSE_CORS_ORIGIN: '*'
#SKIP_DB_AND_REDIS: '1'
nginx:
image: fholzer/nginx-brotli
# command: /bin/sh -c "envsubst \u003c /etc/nginx/conf.d/discourse.template.conf \u003e /etc/nginx/conf.d/default.conf \u0026\u0026 nginx -g 'daemon off;'"
ports:
- 3001:80
depends_on:
- discourse
networks:
- discourse-net
volumes:
- ./config/nginx.application.conf:/etc/nginx/conf.d/default.conf
- ./generated/public:/var/www/discourse/public
- ./generated/nginx/cache:/var/nginx/cache
Funziona splendidamente; tutto il traffico passa tramite nginx, che condivide anche l’output di assets:precompile.
I prossimi passi consistono semplicemente nell’avere una serie di chiamate all’immagine per precompilare gli asset ed eseguire db:migrate “on demand” o semplicemente usare exec per fare la stessa cosa (poiché questi elementi non cambiano spesso) e forse vedere se riesco a ridurre la dimensione di questa immagine da 2,6 GB…
Sembra molto più pulito, come accennato prima, la funzionalità pup è ok e posso apprezzare ciò che offre. Ho diverse riserve sulla build in cui viene eseguita e sull’uso di strategie sudo… (questo è molto raramente il modo in cui io o chiunque io conosca lavora). Di solito le immagini vengono costruite in modo indipendente e distribuite altrove (kube, saltstack, nomad, docker-compose).
Ho una potenziale PR per aggiungere un sample/kube.yml e applications/kubernetes.template.yml, poiché ci sono certi elementi, override e impostazioni per disabilitare db e redis e poi effettivamente disabilitare redis e db anche durante la build, oltre a disabilitare precompile… se questo è interessante.
È stata un’esperienza interessante, grazie per il bump…
C’è solo una piccola stranezza relativa ai fixture (forse dovuta all’avvio di migrate alcune volte)
vedi l’immagine allegata
Credo che docker-compose sia stato basato su uno strumento chiamato “fig”.
