Share
Este artículo lo ayudará a usar Vagrant para administrar sus instancias de máquinas virtuales y le explicará cómo puede aprovechar Puppet para aprovisionar varios recursos, como PHP y PostgreSQL..
Los desarrolladores tienen una gran selección de formas de construir su entorno de desarrollo web.
Los desarrolladores tienen una gran selección de formas de construir su entorno de desarrollo web. Puede usar las opciones "locales", como instalar pilas de servidores "todo en uno" pre-compuestas, como el servidor Zend, XAMPP, MAMP, WAMP, etc., o puede instalar los componentes desde la fuente o a través de sistemas de gestión de paquetes como Homebrew, Apt y Yum.
Esto puede acumularse a medida que trabaja en varios proyectos con: PHP 5.3 y PHP 5.4, MySQL, SQLite, MongoDB, Postgres, PEAR, PHPUnit, Rails 3.1, Memcached, Redis, Gearman, NodeJS, etc. Si actualiza o su computadora muere , tendrás que empezar de nuevo.
Podría tener una configuración "remota", utilizando un servidor en la red con recursos compartidos de Samba o un servidor SSH montado con una herramienta como ExpanDrive. La última opción puede llevar a la latencia en las lecturas / escrituras de archivos, que son extremadamente molestas. Puedes usar SSH + Vim para todo, lo cual es rápido, pero solo funciona si quieres usar Vim para todo.
Si bien puede estar contento con cómo está haciendo las cosas en este momento, cuántos de ustedes han escuchado (o han dicho) "Bueno, funciona en mi computadora". Esto es terriblemente común y ocurre cuando los entornos difieren por el detalle más trivial..
Es extremadamente importante asegurarse de que su entorno de desarrollo sea idéntico al entorno de producción, y que coincida con los servidores de prueba y de prueba si también los tiene.
Eso podría parecer fácil si solo piensa en instalar Apache, PHP y alguna copia de MySQL, pero hay un millón de factores en los que pensar. Si se está desarrollando en OSX y se está implementando en un sistema Ubuntu, entonces notará problemas divertidos con la capitalización de archivos. Esto es común en CodeIgniter, cuando alguien tiene una biblioteca con una primera letra minúscula. Se cargará bien en OSX, pero se romperá cuando se implemente en producción. Tu proceso de desarrollo podría haberte perdido algún negocio, todo debido a una diferencia trivial del sistema operativo que nadie pensó hasta que fue demasiado tarde.
Forzar a los desarrolladores a usar el mismo sistema operativo va a llevar a problemas.
¿Entonces, cuál es la solución? ¿Forzar a todos sus desarrolladores a desechar sus diferentes herramientas y desarrollarlas exactamente en el mismo modelo de computadora portátil? Si todos los desarrolladores obtienen Macbooks nuevos, es posible que no recibas demasiadas quejas, pero entonces deberías usar OSX Server para todo..
Puedes usar Linux para todo, pero luego tienes que luchar sobre qué distribución usar. Forzar a los desarrolladores a usar el mismo sistema operativo llevará a problemas, reducirá la productividad y promoverá la lucha contra nerd.
La virtualización es la respuesta y no es nada nuevo, pero cuando la gente piensa en la virtualización, a menudo piensa en los problemas de rendimiento y sus fanáticos giran como locos mientras su computadora portátil intenta desesperadamente ejecutar dos sistemas operativos..
Este aún puede ser el caso al intentar ejecutar Windows en una máquina de baja potencia, pero en estos días, una Mac promedio tiene 4 GB de RAM listos para usar, lo que es más que suficiente para impulsar una instalación de servidor Ubuntu que se ejecuta en el modo de línea de comandos y todas sus herramientas de desarrollo habituales (IDE, navegador, herramientas de depuración, etc.). Hay algunas opciones para la virtualización, pero prefiero VirtualBox de Oracle (que es gratis). Este software hace todo el trabajo pesado para la virtualización, luego una herramienta llamada Vagrant administra las instancias..
Primero descarga VirtualBox e instálalo. En los sistemas * nix (Mac OSX, Linux, etc.), deberá modificar su .bash_profile (o .zsh_profile) para extender su $ PATH variable:
PATH = $ PATH: /Applications/VirtualBox.app/Contents/MacOS/ export PATH
Esto permitirá a Vagrant saber dónde está instalado VirtualBox y, por supuesto, variará para diferentes sistemas operativos.
Puedes descargar una compilación errante para tu sistema operativo, o instalarla como una gema si no hay una disponible:
$ gem install vagrant
Haz un lugar para que tus configuraciones vagabundas vivan:
mkdir -p ~ / Vagrant / test cd ~ / Vagrant / test
Estaremos usando Ubuntu 12.04 LTS (Precise Pangolin), que ya tiene una "caja" configurada.
vagrant box add precise32 http://files.vagrantup.com/precise32.box
Aquí puede ver el argumento "precise32", que es un apodo para la URL. Ahora puede crear una instancia, que descargará este .box.
vagrant init precise32 vagrant up
Ahora estará funcionando. ¡Fácil! Si desea ingresar a esta instancia, a través de SSH, use este comando:
vagabundo ssh
Tendrás un archivo, llamado Vagrantfile, que contiene la configuración para esta instancia:
Accentsconagua
# - * - mode: ruby - * - # vi: set ft = ruby: Vagrant :: Config.run do | config | config.vm.box = "precise32" config.vm.box_url = "http://files.vagrantup.com/precise32.box" # Asigne esta máquina virtual a una red IP de host únicamente, lo que le permite acceder a ella a través de IP Las redes solo de host pueden comunicarse con la máquina host así como con # otras máquinas en la misma red, pero ninguna red externa puede acceder a ella (a través de esta # interfaz de red). config.vm.network: hostonly, "192.168.33.10" # Configure el recurso compartido predeterminado del proyecto para que use nfs config.vm.share_folder ("v-web", "/ vagrant / www", "./www",: nfs = > true) config.vm.share_folder ("v-db", "/ vagrant / db", "./db",: nfs => true) # Reenvía un puerto desde el invitado al host, lo que permite el exterior # equipos para acceder a la máquina virtual, mientras que las redes de host solo no lo hacen. config.vm.forward_port 80, 8080 # Establezca la zona horaria en algo útil config.vm.provision: shell,: inline => "echo \" Europe / London \ "| sudo tee / etc / timezone && dpkg-reconfigure --frontend tzdata no interactivo "# Actualizar el servidor config.vm.provision: shell,: inline =>" apt-get update --fix-missing "# Habilitar Puppet config.vm.provision: puppet do | puppet | puppet.facter = "fqdn" => "local.pyrocms", "hostname" => "www" puppet.manifests_path = "puppet / manifests" puppet.manifest_file = "ubuntu-apache2-pgsql-php5.pp" puppet .module_path = extremo "puppet / modules" final Esto, si no lo has notado, es la sintaxis de Ruby; para que pueda obtener bastante creativo con este archivo, pero esto es lo básico.
Mostrará qué apodo usar y tendrá la URL en caso de que el apodo no esté configurado localmente (bueno para compartir).
los compartir carpeta las líneas son realmente útiles para asignar una carpeta en la instancia a una carpeta local. Utilizando nfs => true La instancia podrá escribir y cambiar los permisos de los archivos, lo cual es útil si, por ejemplo, está intentando instalar un CMS allí..
El reenvío de puertos le permite acceder a su instancia en http: // localhost: 8080 y, por supuesto, cambiar eso a un puerto diferente si eso entra en conflicto.
Este archivo de configuración también establecerá la zona horaria en Europa / Londres, luego ejecutará apt-get update, lo que debería obligar a su sistema a estar actualizado cada vez que se inicia. Si omite este elemento de configuración, es posible que varios paquetes se nieguen a instalar porque las referencias están desactualizadas..
Cuando cambia la configuración, puede volver a cargar la instancia para usarla:
recarga errante
Ahora que nuestros servidores están funcionando y listos para funcionar, necesitamos instalar algún software. No solo vamos a apt-get install un montón de paquetes a través de la línea de comandos, vamos a "aprovisionar" nuestros servidores.
El aprovisionamiento de servidores no es algo en lo que muchos desarrolladores deban pensar.
El aprovisionamiento de servidores no es algo en lo que muchos desarrolladores deban pensar, ya que normalmente se deja a los administradores de sistemas. La idea es hacer un registro de qué software y configuración se ha realizado en un servidor para que pueda crear nuevos entornos de desarrollo, nuevos servidores de prueba que replican la producción o hacer que otro servidor de producción equilibre la carga entre los dos..
La forma en que los administradores de sistemas manejan esto varía, pero se han utilizado todo tipo de soluciones en el pasado, desde mantener un wiki de comandos ejecutados (que pueden volverse grandes y obsoletos rápidamente) y el enfoque asombroso de tener un "multi-terminal", donde escribe los comandos en una ventana y replica los mismos comandos en otros 7 servidores al mismo tiempo. Todos estos métodos son terribles..
Una solución sería construir tu propio .caja archivo, o crear .Yo asi las copias de seguridad para que los nuevos servidores puedan basarse en eso, pero el mantenimiento de esas imágenes genera mucho trabajo adicional, y no importa cuánto lo intentes, esas máquinas de desarrollo se desincronizarán a medida que pase el tiempo.
Hay dos sistemas populares en este momento, llamados Puppet y Chef.
Hay dos sistemas populares en este momento, llamados Puppet y Chef. Ambos han existido durante años, pero se han vuelto más populares con el aumento del método de desarrollo DevOps. Las ideas para ambos son similares y debes investigar ambos sistemas, pero este tutorial se centrará exclusivamente en Puppet.
Esencialmente, en lugar de ejecutar un montón de comandos y esperar que todo funcione bien, crea un manifiesto para Puppet explicando todo lo que necesita para asegurarse de que se haya hecho. Cuando ejecuta un comando en el terminal, básicamente le está diciendo a la computadora:
"Instalar Apache"
Con Puppet, diríamos:
"Asegúrate de que Apache está instalado"
O, en lugar de:
"Hacer una nueva carpeta, llamada
/ var / wwwy establecer permisos para www-data: www-data "
Con Puppet, diríamos:
"Asegurar
/ var / wwwexiste y tiene permisos que coinciden con www-data: www-data "
La diferencia aquí es que estos manifiestos se pueden ejecutar varias veces (en un trabajo cron por hora o por día) para mantener las cosas actualizadas, y no habrá resultados inesperados de algo que se intenta instalar dos veces.
También le ayudará a probar que todo se está ejecutando como se espera, ya que el fallar de cualquiera de estas reglas arrojará errores que son más fáciles de rastrear que la obtención de una gran cantidad de resultados del comando bash. Puppet producirá grandes errores de color rojo que le informarán que PHP no se instaló o que no se pudo configurar un módulo específico.
Los manifiestos son un poco confusos al principio, pero, después de un tiempo, comienzan a tener sentido..
Para repasar un ejemplo básico:
archivo 'testfile': ruta => '/ tmp / testfile', asegurar => presente, modo => 0640, contenido => "Soy un archivo de prueba.",
No hay necesidad de explicar lo que está pasando aquí, ¿verdad??
Más adelante, se puede hacer referencia a este archivo en su manifiesto como "archivo de prueba", lo que significa que se puede enumerar como una dependencia para otras acciones.
Para más ejemplos, nos referiremos a los manifiestos de PyroCMS Puppet en GitHub.
include apache $ docroot = '/ vagrant / www / pyrocms /' $ db_location = "/ vagrant/db/pyrocms.sqlite" # Clase de configuración de Apache 'apache :: php': apache :: vhost 'local.pyrocms' : priority => '20', port => '80', docroot => $ docroot, configure_firewall => false, a2mod 'rewrite': asegúrese => present;
Esto incluye el módulo "apache", configura algunas variables, ejecuta el manifiesto adicional "apache :: php" en el módulo apache, configura un host virtual y luego se asegura de que "mod_rewrite" esté habilitado.
Todas estas clases se definen en el módulo de Apache que incluimos.
Continuando, también queremos instalar PHP:
incluye php php :: module ['xdebug', 'pgsql', 'curl', 'gd']: Notify => [Service ['httpd'],], php :: conf ['pdo', ' pdo_pgsql ']: require => Package [' php5-pgsql '], notification => Service [' httpd '],
Este trozo de manifiesto instalará las extensiones de PHP que necesitamos, luego el notificar La opción le permitirá a Apache saber que ha instalado una nueva configuración, lo que significa que se reiniciará.
incluya la clase postgresql 'postgresql :: server': postgresql :: db 'pyrocms': owner => 'pyrocms', password => 'password',
Esto configurará un servidor de Postgres, creará una base de datos, llamada "pyrocms" y se asegurará de que exista un usuario llamado "pyrocms" con la contraseña proporcionada.
¡Casi terminado! El último paso es asegurarse de que tiene archivos y carpetas de escritura correctamente configurados:
archivo $ docroot: asegúrese => 'directorio', archivo "$ docroot sistema / cms / config / config.php": asegúrese => "presente", modo => "0666", requiera => Archivo [ $ docroot], $ writeable_dirs = ["$ docroot system / cms / cache /", "$ docroot system / cms / config /", "$ docroot addons /", "$ docroot activo / cache / "," $ docroot uploads / "] file $ writeable_dirs: asegúrese =>" directory ", mode => '0777', require => File [$ docroot],
Esto asegurará que la raíz del documento de Apache esté allí, que el archivo de configuración esté establecido en 0666 y que algunas carpetas de escritura estén configuradas en 777.
Ahi lo tenemos!
Para ejecutar todo esto, simplemente reinicie su instancia errante, o ejecute:
provisión vaga
Si todo ha funcionado correctamente, debería ver un montón de texto azul que indica que todo se está instalando, pero si algo sale mal, verá rojo. Google esos errores y vuelva a intentarlo.
Los módulos que se utilizan aquí son: Apache, Postgres, PHP y se puede ver todo en acción clonando el repositorio de PyroCMS Vagrant:
git clone - recursive git: //github.com/pyrocms/devops-vagrant.git ~ / vagrant / pyrocms cd ~ / vagrant / pyrocms vagrant up
Apunta tu navegador a http: // localhost: 8089 / y deberías ver el instalador. Cosas fáciles, eh?
Nota: Esto se instalará con MySQL, ya que el soporte Postgres de PyroCMS y SQLite aún está en desarrollo, a la espera de que se completen algunas características de CodeIgniter PDO. Si está interesado, puede experimentar cambiando el Vagrantfile para usar el ubuntu-apache2-pgsql-php5.pp Manifiesta, destruye la instancia, luego vuelve a iniciarla. El submódulo pyrocms también tendrá que verificarse para feature / pdo
En este artículo, utilizamos Vagrant, VirtualBox y Puppet no solo para configurar una instancia de servidor para que trabajemos, sino que creamos una suite de prueba para nuestro servidor para garantizar que todo se ejecute, instale y configure correctamente.
También hemos creado una lista de verificación para los requisitos y, en el futuro, podremos crear cualquier número de servidores idénticos en minutos, no en horas!
