¿Qué puede estar detrás de las palabras "la escuela en línea más grande de Europa"? Por un lado, esto es mil lecciones por hora, 10 mil maestros, 100 mil estudiantes. Y para mí, un ingeniero de infraestructura, esto también incluye más de 200 servidores, cientos de servicios (micro y no muy), nombres de dominio del segundo al sexto nivel. En todas partes necesita SSL y, en consecuencia, un certificado para ello.
En su mayor parte, utilizamos los certificados Let's Encrypt. Sus ventajas son que son gratuitas y el recibo está totalmente automatizado. Por otro lado, tienen una característica: corta - solo tres meses - validez. En consecuencia, deben actualizarse con frecuencia. Intentamos automatizarlo de alguna manera, pero aún había mucho trabajo manual y algo se rompía constantemente. Hace un año, se nos ocurrió un método simple y confiable para actualizar este montón de certificados y desde entonces nos olvidamos de este problema.De un certificado en un servidor a cientos en varios centros de datos
Había una vez un solo servidor. Y en él vivía un certbot, que trabajaba desde debajo de la corona. Luego, un servidor dejó de hacer frente a la carga, por lo que apareció otro servidor. Y luego más y más. Cada uno de ellos tenía sus propios certificados con su propio conjunto único de nombres, y en todas partes era necesario configurar su actualización. En algún lugar durante la extensión, copiaron los certificados existentes, pero olvidaron la actualización.Para obtener un certificado Let's Encrypt, debe confirmar la propiedad del nombre de dominio especificado en el certificado. Esto generalmente se hace con una solicitud HTTP inversa.Aquí hay un par de dificultades estándar que encontramos a medida que crecíamos:- : . .
- HTTP. , . . - LDAP. - . .
En algunos lugares, los certificados autofirmados se han utilizado durante bastante tiempo, y esto parecía una buena solución en aquellos lugares donde no se necesita autenticación, por ejemplo, para pruebas internas. Para evitar que el navegador informe constantemente sobre un "sitio sospechoso", solo necesita agregar nuestro certificado raíz a la lista de confiables, y el punto está en el sombrero. Pero aquí también surgieron dificultades posteriores.
El problema es que en BrowserStack, que utilizan los probadores, es imposible agregar un certificado a la lista de confianza para al menos iPad, Mac, iPhone. Por lo tanto, los evaluadores tuvieron que soportar advertencias emergentes constantemente sobre sitios peligrosos.Busca una solución
Por supuesto, antes que nada, debe hacer un monitoreo para averiguar acerca de los certificados que finalizan no cuando ya han finalizado, sino un poco antes. Oh bien. El monitoreo es que ahora sabemos que los certificados terminarán pronto aquí y allá. ¿Y ahora qué puedo hacer?
Big Ear es un viejo bot que no arruinará un certificado.¿Y usemos certificados comodín? Vamos! Let's Encrypt ya los emite. Es cierto que deberá configurar la confirmación de la propiedad del dominio a través de DNS. Y nuestro DNS vive en AWS Route53. Y debe descomponer los detalles de acceso en AWS en todos los servidores. Y con la llegada de nuevos servidores, copie toda esta economía allí también.Bueno, los nombres de tercer nivel están cubiertos por comodines. ¿Y qué hacer con los nombres del 4to nivel y superior? Tenemos muchos equipos que se dedican al desarrollo de diversos servicios. Ahora se acostumbra dividir el frontend y el backend. Y si el frontend obtiene un nombre de tercer nivel como service.skyeng.ru , entonces el backend intenta dar el nombre api.service.skyeng.ru . Hmm, ¿tal vez les prohíben continuar haciendo esto? ¡Gran idea! ¿Y qué hacer con docenas de los existentes? ¿Podría ser con mano de hierro conducirlos a todos en un nombre de dominio? Reemplace todos estos nombres de diferentes niveles con URL como skyeng.ru/service. Técnicamente, esta es una opción, pero ¿cuánto tiempo lleva? ¿Y cómo pueden las empresas justificar la necesidad de tales acciones? Tenemos más de 30 equipos de desarrollo, cada uno persuade: llevará al menos seis meses. Y estamos creando un único punto de falla. Nos guste o no, esta es una decisión controvertida.¿Qué otras ideas hay? .. ¿ Tal vez se pueda hacer un certificado donde incluyamos todo-todo-todo? Y lo instalaremos en todos los servidores. Esta podría ser la solución a nuestros problemas, pero Let's Encrypt le permite tener solo 100 nombres en el certificado, y ya tenemos más de un microservicio.¿Qué hacer con los probadores? No se les ocurrió nada, pero se quejan constantemente. Toda la mierda excepto las abejas. Las abejas también son basura, pero hay muchas. Cada desarrollador o evaluador recibe un servidor de prueba; los llamamos pruebas. Las pruebas no son abejas, pero ya hay más de cien. Y para cada uno se implementan todos los proyectos. Eso es todo. Y si para la venta necesita N certificados, entonces hay la misma cantidad para cada prueba. Hasta ahora, están autofirmados. Sería genial reemplazarlos por otros reales ...Dos libros de jugadas y una fuente de verdad
El cisne, el cáncer y el lucio no llevarán el carrito a ninguna parte. Necesitamos un solo centro de control del servidor. En nuestro caso, esto es Ansible. Certbot en cada servidor es malo. Deje que todos los certificados se almacenen en un solo lugar. Si alguien necesita un certificado, ven a este lugar y toma la última versión del estante. Y nos aseguraremos de que los certificados estén siempre actualizados en esta tienda.Los detalles de acceso de AWS también están presentes en un solo lugar. En consecuencia, las preguntas desaparecen, como configurar AWS CLI en un nuevo servidor, que tiene acceso a Route53 y similares.Todos los certificados requeridos se describen en un archivo en Ansible en formato YAML: certificates:
- common_name: skyeng.ru
alt_names:
- *.skyeng.ru
- common_name: olympiad.skyeng.ru
alt_names:
- *.olympiad.skyeng.ru
- api.content.olympiad.skyeng.ru
- games.skyeng.ru
- common_name: skyeng.tech
alt_names:
- *.skyeng.tech
. . .
Se lanza un libro de jugadas periódicamente, que pasa por esta lista y hace su trabajo duro, esencialmente lo mismo que certbot:- crea una cuenta con Let's Encrypt Certificate Authority
- genera una clave privada
- genera un certificado (aún no firmado): la llamada solicitud de firma de certificado
- envía una solicitud de firma
- recibe un desafío de DNS
- pone los registros recibidos en DNS
- envía una solicitud de firma nuevamente
- y, después de haber recibido finalmente el certificado firmado, lo pone en la tienda.
El libro de jugadas se realiza una vez al día. Si no pudo renovar ningún certificado por algún motivo, ya sean problemas de red o algunos errores del lado de Let's Encrypt, esto no es un problema. Se actualizará la próxima vez.Ahora, cuando se necesita SSL en algún host de servicio, puede ir a este repositorio y obtener algunos archivos desde allí, la operación más simple que realiza el segundo libro de jugadas ... Los certificados necesarios en este host se describen en los parámetros de este host, en inventarios / host_vars / server .yml : certificates:
- common_name: skyeng.ru
handler: reload nginx
- common_name: crm.skyeng.ru
. . .
Si los archivos han cambiado, Ansible tira de un gancho; es típico reiniciar Nginx (en nuestro caso, esta es la acción predeterminada). Y de la misma manera, puede obtener certificados de otras CA que utilizan el protocolo ACME.Total
- Teníamos muchas configuraciones diferentes. Algo se rompía constantemente. A menudo tenía que escalar servidores y descubrir qué se había vuelto a caer.
- Ahora tenemos dos libros de jugadas y todo está grabado en un solo lugar. Todo funciona como un reloj. La vida se ha vuelto más aburrida.
Pruebas
Sí, ¿qué pasa con los probadores con sus pruebas? Cada desarrollador o evaluador recibe un servidor de prueba personal: prueba. Actualmente hay alrededor de 200. Tienen nombres de la forma test-y123.skyeng.link , donde 123 es el número de prueba. La creación y eliminación de pruebas está automatizada. Uno de los componentes de la acción es la instalación de un certificado SSL en él. Se genera un certificado SSL por adelantado, con nombres por plantilla: ssl_cert_pattern:
- *
- *.auth
- *.bill
. . .
Solo unos 30 nombres. Entonces el certificado viene con nombres test-y123.skyeng.link
*.test-y123.skyeng.link
*.auth.test-y123.skyeng.link
*.bill.test-y123.skyeng.link
etc.Después del despido del desarrollador o evaluador, se eliminan sus pruebas. El certificado permanece listo para usar. Es todo lo que se almacena. Tú mismo sabes dónde se descompone en hosts; tú mismo sabes cómo.PD
Repositorio con código .También puede ser interesante leer sobre este tema cómo Stack Overflow cambió a HTTPS :- Cientos de dominios de diferentes niveles.
- Websockets
- Muchas API HTTP (problemas de proxy)
- Haz todo y no pierdas rendimiento
Si tiene alguna pregunta, escriba los comentarios, estaremos encantados de responder.