2012-01-09 17 views
6

Tengo una aplicación escrita en PHP, MySQL, etc. La aplicación tiene algunas dependencias como beanstalkd, Solr y algunas extensiones de PHP.Múltiples instalaciones de mi aplicación - ¿cómo la manejo?

Para cada cliente tenemos una instalación separada de la aplicación, ya sea en un servidor compartido con otros clientes o en un servidor con solo ese cliente.

Por ahora estamos usando un script de Puppet para arrancar nuevos clientes y luego vamos manualmente a cada cliente para hacer un git pull, actualizar el db, etc., siempre que algo cambie.

Lo que estamos buscando es realmente una herramienta que tiene como muchas de las siguientes características como sea posible:

  1. interfaz web que nos permite ver todos los clientes y su versión actual
  2. Capacidad para arrancar nuevas instalaciones
  3. capacidad de actualizar las instalaciones existentes a una revisión específica o rama

no estamos buscando una herramienta para arrancar nuevos servidores - que todavía hazlo manualmente En su lugar, estamos buscando una manera de automatizar la configuración de los clientes en un servidor existente.

¿Sería suficiente Chef o Marioneta para esto, hay alguna herramienta más adecuada, o recomendaría rodar algo nosotros mismos?

Respuesta

10

Soy un desarrollador de tiempo completo que trabaja en Puppet en Puppet Labs. También soy el coautor de Pro Puppet.

El títere es sin duda suficiente para sus objetivos. Esta es una forma de resolver este problema usando Puppet. En primer lugar, abordaré la administración de dependencias, ya que solo deberían administrarse una vez, independientemente de cuántas instancias de la aplicación se administren. Luego, me referiré a cómo manejar múltiples instalaciones de su aplicación utilizando un tipo de recurso definido en Puppet y el tipo de recurso vcsrepo.

Primero, con respecto a la organización del código de marionetas para manejar múltiples instalaciones de la misma aplicación. Las dependencias que mencione como beanstalkd, solr y las extensiones de PHP se deben modelar utilizando una clase Puppet. Esta clase se incluirá en el catálogo de configuración solo una vez, independientemente de cuántas copias de la aplicación se administren en el nodo. Un ejemplo de esta clase podría ser algo como:

# <modulepath>/site/manifests/app_dependencies.pp 
class site::app_dependencies { 
    # Make all package resources in this class default to 
    # being managed as installed on the node 
    Package { ensure => installed } 
    # Now manage the dependencies 
    package { 'php': } 
    package { 'solr': } 
    package { 'beanstalk': } 
    # The beanstalk worker queue service needs to be running 
    service { 'beanstalkd': 
    ensure => running, 
    require => Package['beanstalk'], 
    } 
} 

Ahora que tiene sus dependencias en una clase, sólo tiene que incluir esta clase en los nodos donde se implementará la aplicación. Esto generalmente ocurre en el archivo site.pp o en Puppet Dashboard si está utilizando la interfaz web.

# $(puppet config print confdir)/manifests/site.pp 
node www01 { 
    include site::app_dependencies 
} 

A continuación, necesita una forma de declarar varias instancias de la aplicación en el sistema. Desafortunadamente, no hay una manera fácil de hacerlo desde una interfaz web en este momento, pero es posible usar manifiestos de Puppet y un tipo de recurso definido. Esta solución usa el recurso vcsrepo para administrar el proceso de recuperación del repositorio git para la aplicación.

# <modulepath>/myapp/manifests/instance.pp 
define myapp::instance($git_rev='master') { 
    # Resource defaults. The owner and group might be the web 
    # service account instead of the root account. 
    File { 
    owner => 0, 
    group => 0, 
    mode => 0644, 
    } 
    # Create a directory for the app. The resource title will be copied 
    # into the $name variable when this resource is declared in Puppet 
    file { "/var/lib/myapp/${name}": 
    ensure => directory 
    } 
    # Check out the GIT repository at a specific version 
    vcsrepo { "/var/lib/myapp/${name}/working_copy": 
    ensure => present, 
    provider => git, 
    source => 'git://github.com/puppetlabs/facter.git', 
    revision => $git_rev, 
    } 
} 

Con esta definido tipo de recurso, se puede declarar varias instalaciones de su aplicación, así:

# $(puppet config print confdir)/manifests/site.pp 
node www01 { 
    include site::app_dependencies 
    # Our app instances always need their dependencies to be managed first. 
    Myapp::Instance { require => Class['site::app_dependencies'] } 

    # Multiple instances of the application 
    myapp::instance { 'jeff.acme.com': git_rev => 'tags/1.0.0' } 
    myapp::instance { 'josh.acme.com': git_rev => 'tags/1.0.2' } 
    myapp::instance { 'luke.acme.com': git_rev => 'tags/1.1.0' } 
    myapp::instance { 'teyo.acme.com': git_rev => 'master' } 
} 

Por desgracia, no hay actualmente una herramienta fácil de usar fuera del camino caja para hacer esta información visible desde una GUI web. Sin embargo, es posible hacer, sin embargo, utilizando la API del clasificador de nodo externo. Para obtener más información acerca de la extracción de datos externos en la marioneta consulte estos recursos:

Esperamos que esta información ayuda.

+0

Estoy tratando de hacer algo muy similar, utilizando una interfaz de patrones de fábrica, pero me está costando muchísimo lidiar con los directorios que se comparten entre las instancias. ¿Puedes consultar mi pregunta @ http://serverfault.com/questions/ 442520/puppet-possible-to-use-software-design-patterns-in-modules –

Cuestiones relacionadas