Como migrar config.xml do Weblogic a várias máquinas?

Question

nossa equipe de desenvolvimento desenvolve uma aplicação J2EE que roda em Weblogic 10.3. Cada máquina de desenvolvimento executa sua própria cópia de Weblogic 10,3 servidor de aplicativos. domínio Weblogic do ambiente de desenvolvimento foi inicialmente criado em uma máquina e depois copiado para todas as máquinas utilizando a ferramenta de configuração do Weblogic (bea10 / wlserver_10.3 / common / bin / config.cmd).

Cada máquina de desenvolvimento tem sua própria cópia de config.xml. Todas as frases secretas (aqueles para JDBC fontes de dados etc.) nesse arquivo são criptografadas e a criptografia aparentemente utiliza uma semente diferente em cada máquina, pois a mesma senha tem formulários criptografados diferentes em máquinas diferentes.

O problema é que de vez em quando necessidades Config.xml para atualizado (por exemplo, quando um novo EJB é adicionado) e as atualizações precisam ser aplicadas em todas as máquinas. Como devemos fazer sobre isso? Se nós apenas colocar o arquivo no CVS e atualizar as outras máquinas de lá as senhas criptografadas em cada máquina teria substituído. Isso resulta em paddingexceptions feias quando as tentativas servidor para descriptografar os passphrases originalmente criptografado em outra máquina.

Existe uma tarefa formiga (eu não poderia encontrar um) ou um mecanismo semelhante que iria cuidar de fusão corretamente as alterações em config.xml sem substituir as senhas criptografadas? Ou é possível especificar alguma forma das senhas em texto simples e criptografá-los na primeira partida (eu tenho uma vaga lembrança que isso era possível nas versões anteriores, mas não em 10.3).

Como é que as equipes de desenvolvimento trabalhando em Weblogic lidar com isso?

BR,

Marko

Answer 1

[...] Cada máquina de desenvolvimento tem a sua própria cópia de config.xml. Todos passphrases (aqueles para JDBC datasources etc.) neste arquivo são criptografado ...

Sim, WebLogic Server criptografa todas as senhas de texto simples armazenados em seu arquivo XML de configuração de domínio (s). Isso é para evitar o acesso a informações confidenciais. Quando as senhas são inseridos usando o console de administração ou de script ferramentas, ele será automaticamente criptografados antes de serem armazenados nos arquivos (s) XML de configuração.

... ea criptografia aparentemente, usa uma semente diferente em cada máquina uma vez que a mesma senha tem formas diferentes codificados sobre máquinas diferentes.

Sobre o criptografar utilidade (do Oracle WebLogic Server Java Utilities), a documentação diz:

O weblogic.security.Encrypt criptografa cordas texto puro para uso com o WebLogic Server. O utilitário usa o serviço de criptografia do diretório atual, ou o serviço de criptografia para um diretório raiz de domínio especificado WebLogic Server.

Nota: Um criptografado corda deve ter sido criptografada pelo serviço de criptografia no domínio WebLogic Server onde ele será usado. Se não, o servidor não será capaz de descriptografar a string.

Isto não é mencionado na documentação, mas, AFAIK, Weblogic usa arquivo de sal a senha do domínio (SerializedSystemIni.dat) para criptografar a seqüência de texto claro.

[...] Se nós apenas colocar o arquivo no CVS e atualizar as outras máquinas de lá as senhas criptografadas em cada máquina teria substituído.

Você pode optar por usar senhas em texto puro no config.xml armazenado em seu VCS (se isso não é um problema). Na verdade, antes do WebLogic Server 9.0, as senhas criptografadas iria ficar durante a reinicialização subseqüente. A partir WebLogic Server 9.0, usando senhas em texto puro nos arquivos de configuração é "completamente" suportado apenas para o domínio Desenvolvimento e Weblogic não vai voltar a criptografar as senhas. Em ambos os casos, isso permitiria que as pessoas para verificar o arquivo de configuração sem problemas.

Existe uma tarefa formiga (eu não poderia encontrar um) ou um mecanismo semelhante que iria cuidar de fusão corretamente as alterações em config.xml sem substituir as senhas criptografadas? ...

Eu não tenho certeza estas respostas diretamente sua pergunta, mas o Oracle WebLogic Server oferece tarefas Ant para a maior parte (se não todos) os seus Utilitários Java. Talvez você vai encontrar algo útil lá (confira Configurando um Domínio WebLogic Server Usando o wlconfig Ant Task )

Ou é possível especificar alguma forma das senhas em texto simples e criptografá-los na primeira partida (eu tenho uma vaga lembrança que isso era possível nas versões anteriores, mas não em 10.3).

Como escrevi acima, este foi o comportamento "default" antes Weblogic Server 9.0. Eu não sei se você pode forçar este comportamento para versões posteriores. Claro, você pode sempre usar formiga e criptografar para fazer isso, mas, honestamente, se você permitir que as pessoas para ver senhas em texto puro uma vez, eu realmente não vejo o ponto de criptografar-los após os fatos.

Answer 2

Gostaria de usar algo como mercurial ou git, e usar a funcionalidade de exportação / importação, de modo que as mudanças são movidos em diffs, não em arquivos completos.

instruções curtas

Bem, se você está preso com CVS (me desculpe, eu compartilho sua dor até certo ponto), que você pode considerar a criação de um CVS repo de diffs. Por exemplo. quando uma nova versão do arquivo de configuração é feita, o novo arquivo é diffed para o arquivo antigo eo arquivo diff é adicionado à repo, outros hosts o checkout do CVS e corrigir o arquivo de configuração.

É um hack, mas deve funcionar.

Answer 3

Pessoalmente eu olhar para WLST fazer atualizações de domínio em massa. É realmente simples, mesmo se você não tem experiência com python ou WLST

1. ativar a gravação para um domínio (interface web admin)
2. fazer as alterações em um domínio (interface web admin)
3. ativar as alterações (interface web admin)
4. você deve ter um script python em sua pasta de domínio padrão
5. para cada ambiente
   1. se conectar ao servidor de administração com WLST
   2. aplicar seu script
   3. restart domínio ou servidores gerenciados, se necessário

Atualmente, a empresa que eu trabalho para faz uma coisa semelhante ao que você descreve - cortar ao redor com arquivos domínio do WebLogic e, em seguida, implantar os mesmos arquivos com pequenos ajustes para todos os nossos ambientes. Ao longo dos anos nós acabamos com uma confusão absoluta. Não é apenas o caminho a percorrer.

Answer 4

Nós fizemos isso usando WLST. Nós usamos uma espécie de simples "modelo de domínio" declarativa em python que é bastante abstrato (ou seja, ele não especifica a configuração de diferentes servidores em um cluster, em nossos ambientes de todos os nós devem ser idênticos). Este modelo é bastante curta (2-3 páginas para maiores aplicações que têm mais de 30 conjuntos de conexões, um monte de coisas JMS e alguns provedores JMS estrangeiros). Depois disso, temos 2 roteiros: o primeiro cria um domínio vazio no enviornment-alvo, o 2º aplica-se o modelo de domínio. Para coletar as mudanças que os desenvolvedores fazer no ambiente de "mestre" temos um script que atravessa a configuração de domínio e gera o arquivo de modelo. Usando um diff nesses arquivos modelo, podemos ver o que tem sido alterações.

Isto parece um quadro pesado, mas realmente poupa muito tempo quando temos que gerenciar o desenvolvimento, teste, teste e produção ambientes para 100+ aplicações.

Para os casos menores apenas copiando os arquivos e usando o mesmo SerializedSystemIni.dat deve fazer. Apenas certifique-se de que seu nome de domínio permanece o mesmo, ajustar os endereços / portas. Se você quiser usar SerializedSystemInit.dat diferente, é bastante fácil de fazer isso também, com base nesse código ( http://gustlik.wordpress.com/2008/08/06/decryption-of-configuration-passwords-in-weblogic/ ) é bastante fácil de escrever um utilitário que irá decodificar a senha com SerializedSystemIni.dat original e codificar com um novo. Isso deve fazer o truque.