Date post: | 20-Aug-2015 |
Category: |
Technology |
Upload: | iuri-andreazza |
View: | 118 times |
Download: | 1 times |
Green e Blue labelSwitching the Labels
@iuriandreazza/iuri.andreazza
QUE? wiskycerto?
QUE? wiskycerto?
NO
O que seria isto?
Em Produção
Em Homologação
Em um modelo agil de desenvolvimento temos:plan > code > build > test > release > deploy > operateQuando se homologa um novo release:o Pacote é validado!E o ambiente?GMUD na cara dura não?Lembrar de tudo que foi feito? (temos que sempre manter o histórico não?)Replicar em PRD, ok, mas sempre temos o erro humanoMeio burro isso não?As aplicações geralmente são parametrizadas, porque não o ambiente?Porque não trabalhar com switchs de ambientes?
O que seria isto?
Se alinhado corretamente o que é executado:Troca de ambientesSwitch de DNS na entrega de novos ambientes.Switch de Properties (se a aplicação depende de algo hardcoded).Build do Jenkings pode controlar o deploy de AmbienteBuild do Jenkings pode determinar se algo entra no ar ou nãoAutomação ao nivel extremo, ou seja, build OK, deployControle de máquinas, servers e configurações no nivel da equipe do produto.Sem dependencia humana na demanda de upgrade de tech.Controle total do setup de AplicaçõesAgilidade e rapidez no deploy de novas versões.
O que fazerProcesso de homologação sempre
começa após ultimo SWITCH
Deploy do pacote implica em
Homologação do ambiente
Maior agilidade na troca de
tecnologias e ajustes no ambiente
final
O que fazer com o banco?
Como o produto deve ver isto?
Como aplicarConfigurações devem ser padronizadas
O switch de labels não deve ocorrer
como troca de cuecas!
Temos um tempo de cooldown de
ambiente!
Os labels podem ser aplicados a niveis
diferentes das camadas (webcache,
apache, appserver ...)
Padronização em outras camadas
(firewall, proxy, acessos ...)
Como utilizarCom cuidado, ficar virando ambientes
seguidamente pode ser perigoso.
Ajustes imediados ou emergenciais
podem ser relativamente problemáticos
em caso de descuido
O “chaveamento” de ambientes deve
ser automatizado.
Remoção da ideia de INFRA no produto,
todos os DEVs são responsáveis pelo
ambiente final.
Como esperamosTrocas ageis de ambiente
Evolução confiável e agil de tecnologias
Produto pode iniciar processo de deploy
continuo
Equipe de produto que assume
responsabilidade pelo ambiente com
seus DEV-OPS
Minimizar gargalo no release
Maximizar features liberados
Como o tester ve!Ambiente que vive trocando para
validar
Melhor qualidade, pois quando
ocorre a homologação de pacote é
feito em cima do ambiente final.
Menos stress para ao final executar
a troca.
Um pouco complexo.
Como fica a base de dados????
Como o produto ve!RELEASE!!!
MAIS RELEASES!!!
MUITOS FEATURES LIBERADOS!
MUITA VELOCIDADE! (VUSHHHHHH)
maior agilidade na evolução
redução de gargalos conhecidos
(problema) possivelmente mais
rapidamente entre bugs em
produção.
Como a infra ve!Interessante, mas complicado ...
Como assim trocar servidores?
Não to entendendo direito!
Porque ficar virando ambientes??
E a base de dados?
Não é bem assim subir uma maquina
nova.
E o FS como fica?
Ao menos temos alguns processos!
DEV-OPS mexer em ambientes!?
Algo mais!Cara, cade o BANCO?
Switch de Schemas ou mesmo
Instancias de Banco
Area de espaço sempre
dimensionada
Scripts de Setup de Aplicações
Congelar DB para homologação.
Espelhos meus amigos, ESPELHOS!
Como estamos!Atualmente:
Fase 1: <== Estamos nessa fase!Servidores separados
Deploy direto em um stack
Configuração do stack versionado
Fase 2:Desmanchar Homologação
Subir servers ao nivel de PRD
Padronizar Processos (Scripts, mais Scripts e Processos)
Fase 3:Padronizar Labels para controle via:
Puppet/Chef/Ventriloquist
Estrutura
App App SrvSrv
Banco Banco 11
ApachApachee
CacheCache
Sess. Sess. ManMan
App App SrvSrv
Banco Banco 22
ApachApachee
CacheCache
Sess. Sess. ManMan
Usando Labels Por camada
App App SrvSrv
Banco Banco 11
ApachApachee
CacheCache
Sess. Sess. ManMan
App App SrvSrv
Banco Banco 22
ApachApachee
CacheCache
Sess. Sess. ManMan
Usando Labels Por Stack (Pense Fase 3)
BLBL BLBL
Cache Cache 11
Estrutura Sob Demanda (Utópica)
App App Srv 1Srv 1
Banco Banco 11
ApachApache 1e 1
Cache Cache 11
App App Srv 2Srv 2
Banco Banco 22
ApachApache 2e 2
Cache Cache 22
Usando Labels Por camada
BLBL
Banco Banco NN
App App Srv NSrv N
ApachApache Ne N
Cache Cache NN
ApachApache 2e 2
App App Srv 1Srv 1
{
Máquinas Novas - Automated
Será RemovidoNovo NodeCurrent Node
OS Mirror
Applications SWITCH
Como?Switch de Aplicações também é possivel
#Criar aplicação Ash-3.2# ./configure --prefix=/path/aplicacao_node_Ash-3.2# make; make install;#Criar aplicação Bsh-3.2# ./configure --prefix=/path/aplicacao_node_Bsh-3.2# make; make install;
#### Activate Ash-3.2# ln -sfn /path/aplicacao_node_A /path/aplicacao_finalsh-3.2# /path/aplicacao_final/start_script
#### Activate B (Swith Modes)sh-3.2# /path/aplicacao_final/stop_scriptsh-3.2# ln -sfn /path/aplicacao_node_B /path/aplicacao_finalsh-3.2# /path/aplicacao_final/start_script
Perguntas???
Green e Blue labelSwitching the Labels
@iuriandreazza/iuri.andreazza