Author Archives: Grant Slater

Impulsando el futuro de OpenStreetMap: Un año de mejoras del ingeniero de fiabilidad del sitio de la Fundación OpenStreetMap

Hace poco más de un año, me uní a la Fundación OpenStreetMap (OSMF) con el objetivo de mejorar la fiabilidad y seguridad de la tecnología y la infraestructura que sustenta OpenStreetMap. A lo largo del año pasado, he trabajado estrechamente con el Grupo de Trabajo de Operaciones, un equipo dedicado de voluntarios. Juntos, hemos logrado un progreso significativo en la mejora de nuestros procesos y documentación, fortaleciendo en última instancia nuestra eficacia colectiva. Estoy inmensamente agradecido por el apoyo y la colaboración dentro de este grupo, y estoy encantado de presenciar los notables avances que hemos dado en la construcción de una base sólida para el futuro de OpenStreetMap.

Entraré en un poco de detalle a continuación sobre lo que se ha hecho. A un alto nivel, facilité la administración de la implementación del software que se ejecuta en nuestros servidores; fortalecí nuestra infraestructura de red a través de una mejor redundancia, monitoreo, acceso y documentación; aumenté nuestro uso de servicios en la nube para la representación de teselas, aprovechando un generoso patrocinio de AWS; mejoré nuestras prácticas de seguridad; actualicé nuestros entornos de desarrolladores; y por último, pero definitivamente no menos importante, finalicé la migración de 16 años de contenido de nuestros antiguos foros a nuestros nuevos foros.

Si quieres saber más de mí en el transcurso del trabajo del año pasado, echa un vistazo a mi charla en State of the Map 2022 y mi entrevista en el podcast GeoMob. Y me encantaría saber de ti, envíame un correo electrónico a osmfuture@firefishy.com.

Detalles de confiabilidad del sitio 2022-2023

Gestión de software en nuestros servidores

Pequeños Componentes de infraestructura en contenedores (GitHub Actions for building)

He puesto en contenedores muchos de nuestros sitios pequeños que se construyeron previamente utilizando métodos a medida en nuestra base de código de chef como parte de la configuración de “Configuración como código”. Se movieron los pasos de compilación a Github Actions. Configuré una base para cualquier proyecto futuro basado en contenedores (“docker”) en el futuro. Estos son nuestros primeros proyectos basados en contenedores / docker alojados en la infraestructura OSMF.

Nuestro código basado en chef ahora es más simple, más seguro y se implementa más rápido.

Pruebas de chef mejoradas (documentación de incorporación de operaciones)

Utilizamos chef.io para la gestión de la infraestructura (configuración) de todos nuestros servidores y el software utilizado en ellos. Durante el último año, las pruebas de cocina del chef test se han extendido y ahora también funcionan en las modernas máquinas Apple Silicon. Las pruebas ahora se ejecutan de manera confiable como parte de nuestros procesos de CI / PR. Las pruebas agregan control de calidad y garantía a los cambios que hacemos. El soporte ARM fue más fácil de agregar porque podíamos usar la cocina de prueba antes de pasar al hardware del servidor ARM.

Tener pruebas confiables debería ayudar a incorporar nuevos colaboradores del chef.

Se reforzó nuestra infraestructura de red

Network Upgrades @ AMS (Nuevos switches, enlaces redundantes duales, Dublín pronto)

Nuestra configuración de red en Ámsterdam no era tan redundante como debería haber sido. El equipo Cisco Small Business que utilizamos se nos había quedado pequeño. Tuvimos cortes de energía inesperados debido a problemas de hardware. El equipo también estaba limitando futuras actualizaciones. El grupo de operaciones decidió reemplazar el hardware con equipos Juniper que habíamos estandarizado en el centro de datos de Dublín. Reemplacé el equipo con un tiempo de inactividad mínimo en un entorno en vivo (<15 minutos).

Los centros de datos de Dublín y Ámsterdam ahora utilizan una configuración estandarizada y más segura. Cada servidor ahora tiene enlaces totalmente vinculados para mejorar la redundancia y el rendimiento. Los switches han mejorado la potencia y la redundancia de la red. Estamos esperando la instalación de los enlaces ascendentes totalmente resistentes (pedido enviado) en el próximo mes.

Acceso fuera de banda a ambos centros de datos (basado en 4G)

Construí e instalé dispositivos de acceso fuera de banda en cada sitio. Los dispositivos están cableados a equipos de red y administración de energía mediante consolas seriales. Los dispositivos fuera de banda tienen un enlace 4G resistente a una red 4G privada (1NCE). Los dispositivos de acceso fuera de banda son Raspberry PI personalizadas con fuentes de alimentación redundantes y 4 conectores seriales.

Documentación de Infraestructura para facilitar el mantenimiento (Racks / Power)

Documenté cada unidad rack, puerto de alimentación (Power Distribution Unit), conexión de red y cable en los centros de datos. Esto facilita la administración de los servidores, reduce los errores y nos permite instruir adecuadamente a las manos remotas (proveedor de soporte externo) para que realicen cualquier cambio en nuestro nombre.

Oxidized (visibilidad de equipos de red)

Nuestra configuración de red y distribución de energía ahora se almacena en git y se informan los cambios. Esto mejora la visibilidad de cualquier cambio, lo que a su vez mejora la seguridad.

La configuración se supervisa continuamente y cualquier desviación de configuración entre nuestros sitios ahora es mucho más fácil de resolver.

Infraestructura Terraform como Código (mejorar la gestión / repetibilidad)

Terraform es una herramienta de infraestructura como código, ahora la usamos para administrar nuestro servicio de monitoreo remoto (statuscake) y estoy en el proceso de implementarlo para administrar nuestra infraestructura de AWS y Fastly.

Anteriormente, todos estos componentes se administraban manualmente utilizando las respectivas interfaces de usuario web. La infraestructura como código permite al equipo de operaciones trabajar colaborativamente en los cambios, mejora la visibilidad y la repetibilidad / reversión de cualquier cambio.

Gestionamos todos los dominios DNS utilizando el código dnscontrol. Se han realizado mejoras incrementales durante el último año, incluida la adición de pruebas de IC para mejorar la colaboración externa.

Aumentó nuestro uso de servicios en la nube

AWS en uso para la infraestructura de representación. Optimización de los costos de AWS. Seguridad mejorada. Copia de seguridad mejorada. Más en trámite

El equipo de operaciones ha ido aumentando lentamente nuestro uso de AWS en los últimos años. He creado varias cuentas de AWS específicas de uso utilizando un modelo de organización de AWS para mejorar la facturación y la seguridad según las directrices de prácticas recomendadas de AWS. Recibimos generosamente el patrocinio de AWS para expandir nuestra infraestructura de renderizado. Creamos la nueva infraestructura de renderizado experimental con la arquitectura ARM con AWS Graviton2 EC2.
No hemos usado anteriormente servidores basados en ARM. Como parte de las mejoras en nuestro chef (configuración como código) habíamos agregado soporte de pruebas locales para Apple Silicon (ARM), solo se requirieron pequeñas adiciones para agregar la compatibilidad requerida para los servidores ARM al chef.

Nos impresionó el rendimiento de las instancias EC2 de AWS Graviton2 para ejecutar la pila de representación de teselas de OSM. También probamos el escalado bajo demanda y la creación de instantáneas de instancias para posibles mejoras adicionales de la pila de render en AWS.
Hemos aumentado nuestro uso de AWS para la copia de seguridad de datos.

Mejoramos nuestra seguridad

Durante el último año se han realizado una serie de mejoras generales de seguridad. Por ejemplo: El acceso al servidor ahora es a través de clave ssh (el acceso con contraseña ahora está deshabilitado). También hemos pasado de un administrador de contraseñas basado en gpg a medida para el equipo de operaciones a usar gopass (versión rica en funciones de https://www.passwordstore.org/), GoPass mejora la administración de claves y el uso compartido del almacén de contraseñas.

Además, también hemos mejorado el bloqueo de nuestras instancias de WordPress al reducir los componentes instalados, deshabilitar las actualizaciones en línea y deshabilitar el acceso XMLRPC. También estamos trabajando para reducir los usuarios con acceso y eliminar los permisos de acceso no utilizados.

Áreas clave documentadas de vulnerabilidad que requieren mejoras (redundancia, seguridad, etc.)

Documentación sobre vulnerabilidad técnica: Estoy elaborando un informe sobre áreas clave de vulnerabilidad que requieren mejoras (Redundancia, Seguridad, etc.). El documento se puede utilizar para enfocar la inversión en el futuro para reducir aún más nuestra exposición a los riesgos.

Hemos renovado nuestros entornos de desarrollo

Nuevo servidor de desarrollo

Hemos migrado todos los usuarios de desarrollo a un nuevo servidor de desarrollo en el último año. El servidor antiguo había terminado su vida útil (~ 10 años) y estaba alcanzando límites de capacidad (CPU y almacenamiento). El nuevo servidor se entregó directamente al centro de datos de Ámsterdam, se instaló físicamente con manos remotas y comuniqué la migración, y luego migré todos los usuarios y proyectos.

Subversion retirada

Retiré nuestro viejo repositorio de código svn.openstreetmap.org el año pasado. El repositorio de código se utilizó desde el inicio del proyecto, y contenía un rico historial de desarrollo de código en el proyecto. Convertí el repositorio de código svn a git usando una configuración de reposurgeon personalizada, se prestó atención a mantener el historial de contribuciones completo y vincular correctamente a los contribuyentes anteriores (350+) a las respectivas cuentas de github y relacionadas. Los antiguos enlaces svn se mantuvieron y ahora enlazan al archivo en github https://github.com/openstreetmap/svn-archive.

Migración del foro

En la migración del antiguo foro migramos 1 millón de publicaciones y 16 años de publicaciones a discourse. Todas las publicaciones se convirtieron de fluxbb markdown a la versión de markdown de discourse. Todas las cuentas se fusionaron y la autenticación se convirtió a OpenStreetMap.org “inicio de sesión único” basado en auth.

Todos los enlaces antiguos del foro redirigen (enlace al importado) para corregir el contenido. Usuarios, categorías (países, etc.), temas de hilo y publicaciones individuales.