No soy un hablante nativo. Lo siento por mi ingles. Por favor entiende.
Al desarrollar las aplicaciones del servidor, podría encontrar un problema para administrar la configuración. Por supuesto, este problema se puede encontrar en todos los lugares donde se necesita la gestión de la configuración, así como aplicaciones de servidor.
Si es un principiante o no tiene experiencia con la gestión de configuración, podría ser un poco difícil de hacer. Especialmente, si tiene valores secretos como información de base de datos, credenciales de AWS, puede ser muy peligroso administrar la configuración en VCS (Sistema de control de versiones) abierto como Github, Bitbucket. De hecho, en algunos casos, debido a una administración de configuración descuidada, la aplicación web podría ser pirateada por otros piratas informáticos o apoderarse de los recursos de su servidor, por lo que se factura una tonelada de precio inesperadamente. Por lo tanto, la gestión de la configuración, especialmente la gestión de los valores secretos, es un tema muy importante.
En mi caso, principalmente desarrollé aplicaciones de servidor y administré las configuraciones de diferentes maneras para cada proyecto. Por lo tanto, me gustaría presentar las formas que utilicé para ayudarlo a usted que no conoce bien la administración de configuración.
Utilicé Python principalmente cuando desarrollé las aplicaciones del servidor, por lo que las formas que presentaré funcionan en Python. Por supuesto, estas son las "formas" de administrar la configuración, por lo que también podría usar estas ideas en otros idiomas. No hay ningún problema.
En esta publicación, presentaré 4 formas de administración de la siguiente manera. (Pero, aquí, no hablaré sobre la gestión a gran escala en la infraestructura o los niveles del sistema distribuido. Lo publicaré más adelante)
¡Vamos a explorarlo ahora!
Es una forma muy fácil e intuitiva. Como dice el título, está utilizando la estructura de datos incorporada para administrar la configuración, básicamente, se puede usar de la siguiente manera.
Luego, mira un caso un poco más complicado. Por ejemplo, si es desarrollador web, es posible que necesite diferentes configuraciones para cada entorno de desarrollo, prueba y producción, por lo que puede hacer lo siguiente.
Es fácil e intuitivo de usar porque puede importar el archivo de configuración directamente desde el mismo proyecto y usar la estructura de datos integrada tal como está. Pero, si está utilizando VCS, su base de código estará expuesta al mundo, por lo que podría haber problemas de seguridad si hay valores secretos. Por lo tanto, debe usar datos ficticios (datos no reales) en VCS en lugar de datos secretos reales para protegerlo de ataques de seguridad externos. Y luego reemplazará los datos ficticios con valores de configuración reales en el servidor de producción por sí mismo, pero sería engorroso. Existe una forma un poco más avanzada de utilizar la carga dinámica , de la que hablaremos más adelante.
Por lo tanto, recomiendo esta forma si no tiene valores secretos en la configuración.
De esta forma carga los valores de configuración definidos en un archivo externo, no las estructuras de datos integradas. Es una forma más general porque de esta forma tratará la configuración como solo una configuración , no como parte del código. Veamos los ejemplos básicos para usar los formatos ini y json como configuración. (Tenga en cuenta que configparser
es para Python 3.x, en Python 2.x, debe usar ConfigParser
en su lugar)
También puede usar otros formatos como xml, yaml. El enfoque básico es el mismo, por lo que cualquier formato está bien si hay una forma de analizar esos formatos.
En este enfoque, la configuración se separará del código, por lo que si está utilizando Git, solo puede especificar el archivo para ignorar de VCS. Sin embargo, cuando la configuración está completamente separada de VCS, es posible que su compañero de trabajo no pueda usar la configuración. Por lo tanto, puede usar el siguiente consejo para resolver este problema.
Supongamos que config.json tiene valores de configuración reales. Luego haga un archivo de configuración de ejemplo con un nombre que indique que es un ejemplo como config.json.example. Y debe administrar el único config.json.example en lugar de config.json en VCS. Esto permite que otros desarrolladores conozcan el formato y manipulen la configuración por sí mismos. Por supuesto, deberían cambiar el nombre de ese archivo con config.json para usarlo como configuración correctamente.
De esta forma no se utilizan los archivos, sino las variables de entorno del sistema como valores de configuración.
Los valores de configuración no se administran como un archivo separado, por lo que hay menos riesgo de exposición de valores secretos, y es muy fácil de usar y se puede usar en cualquier parte del código base.
Pero, por supuesto, eventualmente, es posible que deba usar scripts de shell u otros scripts para administrar sistemáticamente todas las variables de entorno. Entonces, si está familiarizado con el sistema y las secuencias de comandos, esta forma es para usted. Sin embargo, si algún entorno no puede usar las variables de entorno como Apache, el servidor web Nginx, debe usar otras formas.
Como se mencionó anteriormente, esta es una forma más avanzada que usar estructuras de datos integradas . La forma anterior debe importar el archivo de configuración .py desde un archivo específico que necesita usar la configuración, por lo tanto, el archivo de configuración debe estar ubicado en la ruta que se puede importar. Pero, en este enfoque, el archivo de configuración no tiene que estar ubicado en una ruta que se pueda importar e incluso puede estar ubicado en otro repositorio.
El principio es tan simple. Simplemente registra y carga la ruta del archivo de configuración .py dinámicamente. Es decir, véase lo siguiente.
Sí, parece muy similar a la primera forma: usar estructuras de datos integradas. Pero, la mayor ventaja de esto es que puede separar el archivo de configuración .py del proyecto en sí. Por lo tanto, esta forma es adecuada cuando se aprovechan las ventajas de la primera y la segunda forma y se desea (o se necesita) separar el archivo de configuración .py del código base del proyecto.
En mi caso, utilicé esta forma para administrar el repositorio de configuración y el repositorio del servidor API de forma independiente. El servidor API solo usa la configuración al importar ese archivo, pero los valores de configuración reales se administraron en otro repositorio. Luego, al aprovisionar los servidores, simplemente cloné ambos repositorios y permití que el servidor API pueda usar la configuración dinámicamente.
Al hacer esto, puede administrar la configuración mientras aprovecha las ventajas de la primera forma y también puede minimizar el riesgo de seguridad y administrar la configuración más fácilmente. Además, especialmente, a medida que crece el tamaño del entorno de configuración, será más fácil y efectivo mantener la configuración independientemente del repositorio del proyecto.
Hasta ahora, hablamos de 4 formas de administrar la configuración. De hecho, depende de sus aplicaciones. Por supuesto, puede mezclarlos y puede haber mejores formas que estas. Y, cuando el sistema es a gran escala, podría ser mejor utilizar herramientas o servicios de terceros que proporcionen principalmente la gestión de la configuración.
Espero que esta publicación ayude a alguien que tenga problemas con la gestión de la configuración.
Hacker Noon es como los hackers empiezan sus tardes. Somos parte de la familia @AMI . Ahora estamos aceptando presentaciones y estamos felices de discutir oportunidades de publicidad y patrocinio .
Para obtener más información, lea nuestra página de información , envíenos un mensaje/me gusta en Facebook o simplemente envíe un tweet/DM a @HackerNoon.
Si disfrutó de esta historia, le recomendamos que lea nuestras historias sobre tecnología más recientes y las historias sobre tecnología de moda. Hasta la próxima, ¡no des por sentadas las realidades del mundo!