Actualización de imagen Docker: Redis 6 y un 25% menos de tamaño de imagen

Noticias y Eventos Anuncios
1

Acabamos de publicar una nueva imagen de contenedor que se utilizará en su próximo comando ./launcher rebuild app. Como siempre, no es necesario cambiar ninguna configuración si ha seguido nuestra Instalación Estándar Oficial de Discourse. Dicho esto, hay nuevas funciones que ayudarán a algunas instalaciones.

Redis 6

Hacemos un uso intenso de Redis en muchas partes de Discourse, ya sea para caché, Sidekiq, MessageBus, bloqueos distribuidos o límites de velocidad. En general, ha sido una opción muy sólida para nosotros.

Sin embargo, en cargas de trabajo muy específicas, Redis puede convertirse en un cuello de botella. Y debido a la naturaleza de un solo hilo de Redis, sumado a nuestra incapacidad de usar múltiples instancias debido a nuestros scripts LUA, esto significaba que era un cuello de botella difícil de evitar.

Afortunadamente, Redis 6 incluye soporte para usar un pool de hilos para operaciones de E/S, y durante nuestras pruebas funciona muy bien con clústeres de Discourse limitados por Redis.

Por lo tanto, si está ejecutando en una máquina con muchos núcleos de CPU y métricas que muestran que Redis lucha por manejar la carga, ahora puede optar por usar hilos para operaciones de escritura mediante la sección de parámetros en app.yml:

params:
  redis_io_threads: "4" # 1 lo desactiva, n>1 usa n-1 hilos adicionales para escrituras de E/S

Imagen más pequeña

Optamos por publicar una imagen de contenedor grande al inicio del proyecto para facilitar que personas no técnicas ejecuten Discourse y manejen todas las dependencias necesarias, versionado, actualizaciones, etc.

Dicho esto, recientemente la imagen comprimida superó los 1 GB, lo cual era un poco demasiado.

Por lo tanto, para mitigar el tamaño cada vez mayor de la imagen, movimos el código fuente de Discourse dentro de la imagen de una copia completa del código fuente a un “clon superficial” que contiene solo la versión más reciente del código.

Este cambio reduce el tamaño de la imagen comprimida en un 25 %, lo que resulta en menos espacio en el servidor necesario y reconstrucciones más rápidas cuando se publica una nueva imagen. También debería controlar el crecimiento de la imagen con el tiempo.

Lo probamos en tests-passed/beta/stable, tanto con reconstrucciones como con actualizaciones web, y no rompe ninguna ruta estándar. Sin embargo, los usuarios que realicen operaciones git más exóticas en los hooks de app.yml podrían tener que adaptar sus personalizaciones.

42 Me gusta
2

¿Qué sucede, si es que ocurre algo, con la experiencia del navegador tras una actualización de Redis? ¿Tiene algún impacto en los recursos almacenados en caché? ¿Se vacían como resultado de la actualización?

3 Me gusta
3

Nada.

Los recursos se guardan en el disco local o en almacenamiento de objetos y se almacenan en caché en la CDN. Redis no tiene impacto en ello.

Los datos de Redis se conservan durante la actualización.

10 Me gusta
4

¿Cuál es el valor predeterminado? ¿1?

5 Me gusta
5

Sí. Proviene del archivo de configuración propio de Redis, donde 1 significa un solo hilo, como en la versión anterior.

8 Me gusta
6

Tengo un caso en el que he añadido:

after_redis:
  - replace:
      filename: "/etc/redis/redis.conf"
      from: /^databases.*/
      to: "databases 50"

Y falla al reconstruir porque:

25:M 01 Dic 2020 20:21:08.830 # FATAL: El archivo de datos fue creado con un servidor Redis configurado para manejar
 más de 16 bases de datos. Saliendo

¿Hay algún otro hook que pueda usar para actualizar el número de bases de datos antes de que intente migrar o hacer lo que sea que haga?

Hmm. Y ahora, después de lo que parece ser una reconstrucción fallida, veo esto en los registros de Docker:

chgrp: grupo no válido: 'syslog'
2 Me gusta
7

¿Por qué necesitas más de una base de datos?

3 Me gusta
8

Multisitio. Múltiples instancias utilizando un solo Redis. Probablemente debería haber usado un contenedor Redis más genérico, pero pensé que seguiría el tuyo.

2 Me gusta
9

:face_with_raised_eyebrow:

¿No utiliza multisitio una única base de datos y los espacios de nombres estándar de claves de Redis? Por lo que sé, las bases de datos de Redis son una capa delgada y tenemos comandos que cruzan sus límites, por lo que no debes confiar en eso.

6 Me gusta
10

Sí, multisite utiliza una base de datos

3 Me gusta
11

Oh. Entonces no es multisitio, sino múltiples instancias ejecutándose en una sola máquina que necesitan cada una su propia base de datos Redis. Solo aumenté el valor predeterminado de 16 a 50 porque me dio pereza mantener un control estricto sobre qué bases de datos de Redis estaban en uso.

Así que, supongo que debería ejecutar un contenedor Redis separado para cada instancia, ¿verdad?

2 Me gusta
12

Sí, de lo contrario podrías tener problemas de interferencia entre ellos.

5 Me gusta
13

¡Oh, maldita sea.

Afortunadamente, aprendí esto en un servidor que solo se usa para pruebas.

¿Para los otros sitios, debería simplemente proporcionarles una nueva instancia de Redis y descartar lo que estaba programado? ¿O hacer una copia de seguridad y restauración?

Por cierto, no he notado ningún problema de interferencia entre bases de datos en el último año o así. :man_shrugging: Y hay una forma de configurar la base de datos.

EDITO: Bueno, la buena noticia es que puedo entrar al contenedor, editar redis.conf, reiniciarlo y vuelve a funcionar.

Si tienes alguna pista sobre cómo mover un sitio de DISCOURSE_REDIS_DB: 12 en un contenedor de Redis a otro contenedor de Redis, me encantaría escucharla. O tal vez simplemente no te importan los trabajos programados?

3 Me gusta
14

Esto. Discourse debería sobrevivir razonablemente a un borrado de Redis. Se pierde algo, pero nada crítico.

7 Me gusta
15

Eso es lo que pensé, ya que no conozco ninguna forma en que las copias de seguridad intenten restaurarlo (pero hay mucho que no sé). Parece que podría hacerlo así: https://stackoverflow.com/questions/23222616/copy-all-keys-from-one-db-to-another-in-redis, y parece que funcionó en una prueba que acabo de realizar, pero será mucho más fácil ajustar mi playbook para simplemente crear un nuevo contenedor de Redis y usarlo.

Gracias.

Ahora a averiguar si ejecutar esos Redis en el servidor de base de datos o en el servidor web…

3 Me gusta
16

Entonces, ¿a qué se refiere db_id: 2 en la configuración de multisite?

2 Me gusta
17

Una configuración obsoleta:

5 Me gusta
18

Jaja. ¡Sí, de hecho es confuso!

Gracias. Estoy trabajando en un tema sobre ‘configuración multisitio con Let’s Encrypt y sin proxy inverso externo’, y cuando lo haga, también limpiaré el otro.

4 Me gusta
19

Solo asegúrate de reiniciar Unicorn justo después de eso, para que vuelva a crear las tareas programadas.
Perderás todo lo que esté en cola, así que necesitas encontrar un buen momento para hacerlo.

6 Me gusta
20

¿Esto sigue funcionando como debería? ¿Existe una línea de comando sencilla para descubrir el tamaño de la imagen comprimida?

1 me gusta