Una conversación lateral con @rosscdh reveló que su objetivo principal es Discourse en Kubernetes. Esta no es una configuración compatible aquí. Existen críticas válidas sobre la forma en que hacemos las cosas en relación con Docker/Kubernetes; sin embargo, hemos elegido este enfoque con launcher para facilitar su uso en el mundo del autoalojamiento.
He reabierto este tema, pero por favor mantengámoslo civil y constructivo.
Pero no era una cosa hasta después de que se desarrolló ./launcher. 
Si quieres lanzar en k8s o algo similar, lo que hago es usar el lanzador para construir la imagen y subirla a algún lugar, y luego hacer que k8s lance esa imagen. El lanzador hace ciertas cosas como migrar la base de datos en las actualizaciones, así que debes prestar atención a cómo funciona eso.
Gracias por eso,
El objetivo es hacerlo más similar a Docker para que pueda ejecutarse en Kubernetes, así como simplemente usando Docker con contenedores independientes.
He logrado usar el lanzador y generar una imagen de más de 2 GB (4 plugins; no puedo hacer 6 debido a los límites).
También lo he configurado con Docker Compose, por lo que ahora es un manual de ejecución limpio.
Estoy familiarizado con GlobalSettings y he modificado ligeramente application.rb y routes.rb, por lo que solo estoy montando personalizaciones.
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 # use the nginx entrypoint
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
## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 3
## TODO: The domain name this Discourse instance will respond to
DISCOURSE_HOSTNAME: discuss.monkey.tech:3001
DOCKER_USE_HOSTNAME: "true"
## Uncomment if you want the container to be started with the same
## hostname (-h option) as specified above (default "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'me@example.com,you@example.com'
## TODO: The SMTP mail server used to validate new accounts and send notifications
# SMTP ADDRESS, username, and password are required
# WARNING the char '#' in SMTP password can cause problems!
DISCOURSE_SMTP_ADDRESS: mailhog
#DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: mailhog
DISCOURSE_SMTP_PASSWORD: password
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
#LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## TODO: configure connectivity to the databases
# DISCOURSE_DB_SOCKET: ''
DISCOURSE_DB_HOST: postgres
DISCOURSE_DB_USERNAME: discourse
DISCOURSE_DB_PASSWORD: password
DISCOURSE_REDIS_HOST: redis
## The http or https CDN address for this Discourse instance (configured to pull)
## see https://meta.discourse.org/t/14857 for details
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 < /etc/nginx/conf.d/discourse.template.conf > /etc/nginx/conf.d/default.conf && 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
Funciona maravillosamente; todo el tráfico se enruta a través de nginx, que también comparte la salida de assets:precompile.
Los siguientes pasos son simplemente tener un conjunto de llamadas a la imagen para precompilar activos y ejecutar db:migrate “bajo demanda” o simplemente usar exec para hacer lo mismo (ya que esos elementos no cambian con tanta frecuencia) y quizás ver si puedo reducir el tamaño de esta imagen de 2.6 GB…
Se siente mucho más limpio; como mencioné antes, la funcionalidad de pup está bien y puedo apreciar lo que ofrece. Tengo varias reservas sobre el proceso de compilación donde se ejecuta y el uso de estrategias con sudo… (esta es muy rara vez la forma en que yo o cualquier persona que conozco trabaja); por lo general, las imágenes se construyen de forma independiente y se despliegan en otro lugar (kube, saltstack, nomad, docker-compose).
Tengo un PR potencial para agregar un sample/kube.yml y applications/kubernetes.template.yml, ya que hay ciertos elementos, anulaciones y configuraciones para deshabilitar la base de datos y Redis, y luego realmente deshabilitar Redis y la base de datos durante la compilación, así como deshabilitar la precompilación… si eso es interesante.
Fue una experiencia interesante, gracias por el impulso…
Solo hay una pequeña rareza relacionada con los fixtures (quizás por llamar a migrate varias veces). Vea la imagen adjunta
Creo que docker-compose se basó en una herramienta llamada “fig”.
