Existen Linux Containers (LXC). Existen scripts de VM. Podrías crear un instalador ISO.
LXC son literalmente contenedores.
Para los administradores de sistemas, esta tontería de Docker es redundante y sin sentido si tienes una configuración de red con firewalls, etc.
Entiendo que esto es una instalación sencilla para aquellos que no saben cómo usar Linux y asegurarlo, pero para los administradores de sistemas, aprender Docker es inútil. LXC y las VM siempre serán mucho mejores que Docker.
Para los administradores de sistemas que gestionan servidores, creamos LXC y VM en una red separada. Así que he creado una VM dedicada para Discourse y luego crear un contenedor Docker. -_-
Así que ahora es una red dentro de una red. Una VM dedicada y aislada y solo para crear un contenedor Docker aislado de todo -_-
No hay ninguna guía para instalarlo sin Docker, independientemente de si viene con soporte o no. No hay guía ni asistencia para exponer la IP del host al contenedor.
Porque cuando empezaron a desarrollar Discourse, era lo mejor que había.
Si lo hicieran hoy, supongo que lo único que harían de manera diferente sería usar docker-compose en lugar de su propio comando personalizado launcher que crea y lanza imágenes de Docker.
Debes estar en una internet diferente a la mía. Por todo lo que veo, la mayoría de las personas que administran software en más de, digamos, 5 servidores, están usando algún tipo de contenedor para administrar las cosas. Cada vez más, los desarrolladores ejecutan cosas en sus portátiles en contenedores para asegurarse de que las versiones de todo se mantengan consistentes.
Incluso administrar un entorno de desarrollo de Discourse/rails/ember en un solo portátil es un desafío.
Eso es cierto. Si quieres un foro que puedas usar sin Docker, no deberías usar Discourse.
Lo apoyo. docker-compose sería 100% mejor, ya que acabo de ver un curso intensivo sobre docker y docker-compose. Parece que si Discourse usara docker-compose, habría resuelto este problema sin necesidad de crear una publicación.
docker-compose hace todo el trabajo pesado similar a lo que hace el lanzador, pero con docker-compose podría haber configurado fácilmente la red y el puente.
Estoy de acuerdo. Yo uso contenedores. Solo contenedores LxC puros. No se requiere software adicional. No es tan simple como eso. Por ejemplo: en uno de mis servidores tengo un paquete de bronce que es básicamente para desarrolladores. Configuración barata y fácil. En el momento en que se confirma un pago, el servidor principal recibe una solicitud para crear un contenedor lxc o una VM según la selección del usuario, obviamente se requiere un nombre de dominio o se emitirá un subdominio personalizado para el servidor (lxc/vm). También le pide al usuario que configure su propia red, que luego no puede ser accedida por la red principal y viceversa. Es básicamente un pequeño AWS.
Para el desarrollo, docker sería excepcional para portátiles y propósitos de desarrollo para separar los archivos principales de la computadora y los archivos de desarrollo, incluidas las redes.
No puedo estar de acuerdo ni en desacuerdo, ya que no he desarrollado nada personalmente con Discourse/rails/ember. eso está fuera de mi alcance y si los desarrolladores dicen que es más fácil, no estoy en posición de discrepar con algo que no sé.
Este es mi problema, he investigado lo suficiente sobre todo el software de foros disponible y he utilizado bastantes de ellos.
Mis opciones se redujeron a 2 foros:
Discourse
Flarum
Elegí Discourse como el mejor software de foro en todos los aspectos y debido a mi única experiencia con docker, que fue Nginx Reverse Proxy Manager.
Pensé que todo lo que tenía que hacer era ingresar parte de mi información en el archivo .yml y luego hacer docker-compose up -d. Me equivoqué.
El problema que tengo actualmente se puede solucionar, solo llevará tiempo descifrarlo.
Me niego a usar Flarum porque he usado Discourse en muchas plataformas y sin ofender a otros buenos softwares de foro que existen, pero Discourse es el mejor foro disponible en el mercado.
Quizás una actualización a docker-compose podría ayudar
Después de una rápida investigación, algunas guías de 5 minutos y algunos videos de YouTube.
No, Docker no es malo en absoluto. Docker es perfecto para desarrolladores que usan su máquina personal para desarrollar o incluso para computadoras de trabajo. Dado que la mayoría de los desarrolladores no usan Linux como su sistema operativo principal, crear contenedores LxC no sería tan fácil. Ahí es donde entra Docker. Soporta todas las plataformas principales, lo que permite a los desarrolladores colaborar fácilmente, y la ventaja sería no estropear todo su sistema con archivos que no están destinados a ser utilizados por el sistema operativo principal.
De hecho, podría entrar en más detalles, pero la última versión de Docker/Docker-Compose es perfecta para Discourse, ya que veo que requiere muchas partes móviles y es bastante fácil agruparlas usando Docker-Compose. De esa manera, si algo sale mal, los desarrolladores sabrán exactamente qué hacer.
Tengo una idea para Discourse, pero primero voy a resolver mi instalación.
Alojar aplicaciones Rails es complicado. Incluso si ya tiene Postgres, Redis y Ruby instalados en su servidor, aún debe preocuparse por ejecutar y monitorear sus procesos Sidekiq y Rails, así como por configurar Nginx. Con Docker, nuestra configuración de Discourse totalmente optimizada está disponible para usted en un contenedor simple, junto con una GUI basada en web que hace que la actualización a nuevas versiones de Discourse sea tan fácil como hacer clic en un botón.
El objetivo principal no es el aislamiento, sino la facilidad de implementación…
No necesitas aislar el contenedor; puedes ejecutarlo en un puente enrutado o en un puente que tenga un puerto perteneciente a tu red interna. El primero es como lo ejecutamos en producción - mira aquí un video de @mpalmer que explica cómo funciona.
Si alguien realmente quiere hacer esto, puede seguir los mismos pasos que el propio Dockerfile para obtener las versiones correctas de todas las herramientas utilizadas por la imagen compatible.
No tenemos una guía ya que requeriría que alguien la mantuviera, y la VASTA mayoría de las personas que quieren esto tienen:
poca experiencia con servidores
conocimientos suficientes para tomar lo que proporcionamos y adaptarlo a sus necesidades
Por ejemplo, sé que hay personas que usan launcher para construir una imagen que se implementa a través de sus propias herramientas (ya sea lxc, kubernetes, lo que sea) y eso funciona para ellos.
Intentar dar soporte (gratis) a todos los que usan su propia instalación personalizada de lo que es un software complicado sería una pesadilla.
Docker es un punto intermedio. Nuestro sistema no es perfecto; ha crecido un poco con el tiempo y ciertamente sentimos el dolor de una refactorización pendiente. Creamos launcher antes de que siquiera existiera docker-compose.
Tenemos la intención de refactorizarlo y/o movernos a docker-compose, pero eso no es una prioridad en este momento.
No es tan difícil hacer que el lanzador inicie Discourse con las variables de entorno necesarias para que Nginx Reverse Proxy funcione. Principalmente, solo agregas la variable de entorno al YML, o las agregas a lo que obtienes de ./launcher start-command app.
docker-compose no fue muy útil cuando Discourse comenzó, y puede que ni siquiera existiera.
¡Odio Docker (es demasiado fácil para mí, cualquier niño puede hacerlo, así que nada especial! ¡Bostezo)! Y en lugar de simplemente escribir el código para que funcione también sin la variante oficial de Docker… ¡no lo entiendo! ¡Incluso el método oficial no funciona!
Y hay personas que quieren desafíos o incluso ya los dominan. ¡Para ellos, Docker es aún más un obstáculo, porque también tienen que lidiar con Docker!
