Gerando / gerenciando arquivos de configuração para o aplicativo hospedado

5

Editar - Estou começando a olhar para o Template-Toolkit do Perl. Parece se encaixar muito bem no problema descrito abaixo. Alguém já brincou com isso? Algum conselho (detalhado)?

Eu fiz uma pergunta sobre o gerenciamento de configuração e não vi uma resposta. É possível que minha pergunta tenha sido muito vaga, então vamos ao assunto. Aqui está o processo que seguimos ao integrar uma nova instância de cliente em nosso aplicativo hospedado: como você gerenciaria isso? Eu estou inclinado para um script Perl para preencher modelos para gerar scripts de shell, arquivos de configuração, arquivos de configuração XML, etc. Olhando brevemente para CFengine e Chef, parece que eles não vão reduzir a quantidade de trabalho, porque eu d ainda tem que especificar manualmente todas as alterações / edições dentro da ferramenta. Não parece ser um grande ganho tocar nos arquivos de configuração diretamente.

  1. Adicionamos uma estrofe ao arquivo de configuração principal do aplicativo principal (de terceiros). Esta estrofe tem valores que
    • define o nome da instância (cliente)
    • a porta do listener TCP para essa instância (não é usada atualmente)
    • o nome do banco de dados DB2 (o identificador numérico serial já existe, eles são inseridos para nós pelos DBAs)
    • três arquivos de subconfiguração, por nome - eles precisam ser criados a partir de três modelos e receber o nome da instância
  2. Os arquivos de sub-configuração definem:
    • O caminho de arquivo para os volumes do DB2
    • O caminho de arquivo para o armazenamento de objetos
    • O caminho de arquivo para apenas um dos volumes do DB2 (sim, redundante para o primeiro item.
  3. Executamos alguns comandos do aplicativo, iniciamos a instância
  4. Fazemos algumas coisas LDAP (criar uma UO para a instância, etc.)
  5. Adicionamos uma estrofe ao arquivo de configuração do nosso ouvinte de segurança que funciona como um repasse para o LDAP
    • nome da instância
    • OU LDAP
    • porta TCP por exemplo
    • nome do banco de dados DB2
  6. Reiniciaremos o ouvinte de segurança (fora do horário de atendimento), alteraremos o arquivo de configuração principal do item 1, pararemos e reiniciaremos a instância. Agora está autenticando via LDAP.
  7. Adicionamos os comandos stop e start para essa instância aos scripts de failover de alta disponibilidade.
  8. Nós importamos um arquivo de configuração XML para a instância que define as coisas para o aplicativo real do cliente - nomes de usuário, grupos, permissões e regras de negócios. O XML é fornecido pela equipe de implementação.

Agora, configuramos o aplicativo de carregamento de dados

  1. Adicionamos uma estrofe ao arquivo de configuração de nível superior existente que aponta para um novo arquivo de configuração no nível do cliente. O novo arquivo de configuração no nível do cliente inclui:
    • o nome da instância (cliente)
    • o nome do banco de dados DB2
    • número arbitrário de arquivos de subconfiguração, por nome
  2. Cada um dos arquivos de sub-configuração define:
    • filepaths para os diretórios para ingestão, feedback, backup e falha
    • esses caminhos de arquivo têm um caminho comum para uma pasta específica do cliente e, em seguida, uma pasta para cada arquivo de subconfiguração
  3. Cada um desses caminhos de arquivo precisa ser criado
  4. Precisamos adicionar essa instância do cliente aos nossos scripts de monitoramento que confirmam que os processos corretos estão em execução e podem ser conectados. Obviamente, esses arquivos de configuração de monitoramento incluem o nome da instância, a porta TCP, o nome do banco de dados DB2, etc.
  5. Há também um aplicativo de relatório que precisa ser configurado para a nova instância. Você entendeu a ideia.
  6. Há também o XML carregado no WAS pela equipe de middleware. Damos a eles os valores para eles se conectarem ao XML - eles poderiam facilmente nos fornecer o modelo e poderíamos devolvê-los a eles.
por mfinni 12.03.2010 / 03:07

2 respostas

2

Eu acho que você poderia usar Bcfg2 com muito sucesso para isso. É um sistema de gerenciamento de configuração que é incrivelmente flexível e extensível. Ele vem com Genshi para lógica de templates básica, mas permite que código Python in-line arbitrário faça coisas mais complicadas.

Você pode ter um único banco de dados que contenha todas as informações sobre cada instância e, em seguida, configurar o Bcfg2 para gerar cada bit de configuração com base nisso. Como um bônus adicional, se você precisar alterar algo em um grande número de instâncias (ou todas as instâncias), será totalmente indolor.

    
por 18.03.2010 / 21:16
0

Isso parece muito personalizado, então eu gostaria de fazer minha própria ferramenta com Fabric para o backend executar todos isso e Django para a interface web.

Com o tecido como backend você também pode usá-lo em ssh sem django.

    
por 18.03.2010 / 17:17