{ myPassion = "Software Development"; }
"Não existe caminho para a felicidade.
A felicidade é o caminho."
Mahatma Gandhi
Talvez haja mais desenvolvedores, além de mim, que tenham detestado os menus do Visual Studio 2012, todos em caixa alta, berrando em maiúsculas:
Esta ‘novidade’ pode ser desabilitada criando um valor DWORD 1 chamado SuppressUppercaseConversion na chave de registro HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General.
Para reeducar os menus a falarem baixo, feche o Visual Studio, clique no menu Iniciar / Executar e entre o seguinte comando:
powershell -nologo -Command Set-ItemProperty -Path HKCU:\Software\Microsoft\VisualStudio\11.0\General -Name SuppressUppercaseConversion -Type DWord -Value 1
Agora, sim! De volta ao normal, apenas com as iniciais em maiúsculas:
Caso queira voltar à forma original, é só executar o comando:
powershell -nologo -Command Remove-ItemProperty -Path HKCU:\Software\Microsoft\VisualStudio\11.0\General -Name SuppressUppercaseConversion
Afinal, gosto não se discute! LAMENTA-SE! (ou melhor… Lamenta-se!)
Este é a quinta parte do tutorial para criar um servidor Jenkins na nuvem, usando a Amazon AWS, e configurá-lo para fazer a integração contínua de um projeto .NET cujo código-fonte está no GitHub.
Na quarta parte, criamos os grupos de segurança e suas respectivas regras que farão o controle de acesso ao nosso servidor Jenkins.
Agora, criaremos no EC2 a instância Windows que será nosso servidor Jenkins e a associaremos aos grupos de segurança criados anteriormente.
Sempre que formos criar uma nova instância no EC2, será necessário possuir um Key Pair (par de chaves). Mas o que é e para que serve?
No caso de instâncias Windows, ao criar uma nova instância, em seu sistema operacional o EC2 cria um usuário administrador, com uma senha gerada automaticamente.
Para que esta senha não fique armazenada de forma desprotegida no EC2, ele utiliza um par de chaves SSH para criptografar a senha antes de armazená-la. Posteriormente, quando você precisar saber a senha, o EC2 utilizará novamente seu par de chaves para descriptografar a senha e exibi-la a você.
Como não temos um par de chaves, vamos criar um no momento da criação da instância Windows e depois usá-lo para obter a senha do administrador.
Quando fizermos o primeiro logon, por questões de segurança, vamos alterar a senha do administrador para uma mais conveniente.
No painel My Resources, podemos ver que já temos 3 grupos de segurança (o grupo default criado automaticamente pelo EC2 e os grupos todos-os-servidores e jenkins que criamos anteriormente).
Será exibida a página de Instâncias, com o painel My Instances mostrando que nenhuma instância foi criada ainda:
Será exibida a janela Create a New Instance:
Será exibido um resumo com as informações da instância.
Será exibida uma lista de seções de configurações, com a seção Instance Details aberta.
Voltará a ser exibido o resumo das informações da instância.
Será exibida uma mensagem, pedindo para aguardar enquanto o processo de criação é iniciado:
Após alguns instantes, é exibida a mensagem final, avisando que a instância está sendo criada e oferecendo algumas ações que podem ser executadas:
Voltará a ser exibido o painel My Instances, mostrando a instância Jenkins, recém criada, com estado (coluna state) running (executando).
Uma vez que a instância esteja executando, já podemos fazer uma conexão remota à mesma usando o Terminal Services.
Será exibido o diálogo Console Connect – Remote Desktop Connection:
Será solicitado que você forneça o par de chaves criado anteriormente, para descriptografar a senha do administrador:
Após selecionar o arquivo, o conteúdo da chave privada aparecerá na caixa de texto, abaixo de Private Key contents.
A senha do administrador será descriptografada e, então, exibida:
Tome nota da senha. Por medida de segurança, nosso primeiro passo ao conectar no servidor será trocar esta senha por alguma outra mais segura.
Uma janela da Conexão da Área de Trabalho Remota (Remote Desktop) será exibida, alertando sobre a conexão que estamos prestes a fazer.
Serão solicitadas as suas credenciais (usuário e senha):
Será iniciada a tentativa de conexão remota com o servidor:
Será exibido um diálogo, alertando para a identidade do servidor remoto.
A tentativa de conexão prossegue:
A conexão, então, é concluída, é feito o logon no Windows como administrador, e a tela inicial para definir o local da conexão de rede do novo servidor é exibida.
O resumo sobre a opção escolhida é exibida.
A senha é, então, alterada. Clique no botão OK para concluir:
Já temos um servidor Windows rodando na nuvem da Amazon! O próximo passo será instalar o Jenkins no servidor e configurá-lo para que possamos acessar sua interface web remotamente. Até o próximo post!
Este é a quarta parte do tutorial para criar um servidor Jenkins na nuvem, usando a Amazon AWS, e configurá-lo para fazer a integração contínua de um projeto .NET cujo código-fonte está no GitHub.
Na terceira parte, definimos os grupos de segurança que serão utilizado para o controle de acesso à instância EC2 que será o nosso servidor Jenkins.
Agora, criaremos no EC2 os grupos de segurança que foram definidos anteriormente.
No Console do AWS, clique em EC2:
Caso seja seu primeiro acesso ao EC2, será exibida uma mensagem avisando que você acaba de realizar a inscrição no serviço e que ela está sendo processada:
Um e-mail será enviado quando o EC2 estiver pronto para o uso. Se não houver problemas, a liberação será praticamente imediata.
Após a liberação, o acesso ao EC2 pode ser feito pelo Console do AWS, ou diretamente por este link para o EC2 (Arraste o link para os favoritos/bookmarks para agilizar futuros acessos).
Esta é a página do EC2:
Os três painés desta página, Getting Started, Service Health e My Resources, mostram informações ou executam ações relacionadas à região atualmente selecionada, no caso, US East (N. Virginia). Sempre que entrar na página, preste atenção à região atual, para não executar ações na região incorreta.
No canto superior esquerdo da página, há o campo Region, que indica a região atualmente selecionada. Mude para a região South America (Sao Paulo):
Os painéis agora refletem a alteração, mostrando informações da região da América do Sul.
Como vimos no artigo anterior, vamos criar os grupos todos-os-servidores e jenkins.
Será exibida a página de Grupos de Segurança, exibindo o grupo default, criado automaticamente:
Será exibida a caixa de diálogo Create Security Group.
O grupo todos-os-servidores aparecerá criado na lista:
O grupo jenkins aparecerá criado na lista:
Agora, para permitir o acesso remoto à instância por Terminal Services, criaremos uma permissão para liberar o acesso de entrada à instância pela porta 3389, no grupo de segurança todos-os-servidores.
Por uma questão de segurança, o ideal é fazer a liberação somente para o endereço IP dos computadores a partir dos quais faremos o acesso remoto. Neste exemplo, você precisará saber qual o endereço IP do seu computador. Isto pode ser facilmente obtido através de um site como o What Is My IP:
Acesse o What Is My IP e tome nota do endereço IP do computador. Nos passos a seguir, sempre que o endereço 999.999.999.999 for utilizado, utilize em seu lugar o endereço IP do seu computador.
No painel inferior, clique na aba Inbound. Ela exibirá um quadro com as regras existentes e um quadro para a inclusão de uma nova regra:
Se você se esquecer do número da porta (3389), pode usar o tipo de regra RDP (de Remote Desktop Protocol), que é equivalente.
Prossiga clicando no botão Add Rule:
O painel inferior agora mostra a regra recém definida:
Note, porém, a mensagem indicando que suas mudanças ainda não foram aplicadas (Your changes have not been applied yet).
Se você clicar em outro grupo de segurança sem clicar neste botão, suas alterações serão perdidas! O procedimento, portanto, consiste em criar e/ou excluir todas as regras desejadas e, ao final, concluir clicando no botão Apply Rule Changes.
Precisamos criar agora a regra que permitirá acesso à interface web do Jenkins.
A porta padrão para acesso por HTTP é a 80. No entanto, por padrão, o Jenkins utiliza a porta 8080.
Se você pretende utilizar a porta padrão do Jenkins (8080), utilize-a nos passos a seguir. Neste tutorial, nós configuraremos o Jenkins para operar pela porta padrão HTTP (80). Por isso, esta será a porta utilizada nos passos abaixo.
Após clicar no botão Add Rule, e depois no botão Apply Rule Changes, a regra estará efetivada:
Já temos todo o controle de acesso definido. O próximo passo será criar a instância para o servidor Jenkins no EC2. Até lá!
Este é a terceira parte do tutorial para criar um servidor Jenkins na nuvem, usando a Amazon AWS, e configurá-lo para fazer a integração contínua de um projeto .NET cujo código-fonte está no GitHub.
Na segunda parte, definimos algumas características para a instância EC2 que será o nosso servidor Jenkins.
A próxima etapa será entender como funciona o controle de acesso às instâncias e definir qual será a nossa abordagem para tal controle.
As instâncias no EC2 são protegidas por um firewall. Para que qualquer acesso, tanto de entrada (computador na Internet acessando recursos na instância) quanto de saída (instância acessando recursos na Internet), possa ocorrer, é necessário configurar uma permissão correspondente.
No EC2, as permissões às instâncias são concedidas através de Grupos de Segurança (Security Groups), da seguinte forma:
Isto permite agrupar conjuntos de permissões em grupos de segurança e aplicá-los em conjunto a diferentes instâncias:
Uma abordagem simples é criar um grupo de segurança para cada instância e um grupo de segurança global, o que permitirá conceder permissões tanto a uma determinada instância quanto a todas as instâncias de uma só vez.
Por exemplo, no caso de instâncias Windows, é comum precisarmos de acesso às mesmas via Terminal Services, o que requer que o acesso pela porta 3389 esteja liberado. Pela abordagem proposta, basta conceder esta permissão ao grupo global, e todos as instâncias honrarão a mesma.
Por outro lado, no caso de um servidor Web servindo um site por HTTP pela porta 80, é necessário liberar o acesso a esta porta para que os usuários possam visitar o site. Isto é feito concedendo a permissão ao grupo de segurança específico da instância do servidor Web.
Quando o número de perfis de acesso for maior e o conjunto de permissões a gerenciar a cada servidor for mais complexo, podem ser criados quantos grupos de segurança forem necessários para manter o controle de acesso organizado.
Para criar um grupo de segurança, basta fornecer um nome, pois tanto a associação com as instâncias quanto a definição das permissões é feita posteriormente. Esta simplicidade requer atenção especial, pois, no momento, não é possível renomear um grupo de acesso. Sendo assim, escolha com muito cuidado os nomes dos seus grupos de segurança antes de criá-los.
O EC2 já cria automaticamente um grupo de segurança chamado default. Em nosso exemplo, ignoraremos este grupo, pois trabalharemos com nomes em português.
Ainda no nosso exemplo, vamos criar um grupo de segurança chamado todos-os-servidores, que será usado por todas as instâncias, e outro chamado jenkins, que será usado exclusivamente pela instância do servidor Jenkins. Definiremos, então, no grupo todos-os-servidores, a permissão de acesso de entrada à porta 3389, para acesso remoto por Terminal Services, e no grupo jenkins, permissão de acesso de entrada à porta 80, pela qual a interface web do Jenkins estará sendo servida por HTTP.
Agora que estão definidas as características da instância e os grupos de segurança, podemos agora passar à próxima parte, que trata da criação destes grupos de segurança e suas regras de acesso no EC2.
Este é a segunda parte do tutorial para criar um servidor Jenkins na nuvem, usando a Amazon AWS, e configurá-lo para fazer a integração contínua de um projeto .NET cujo código-fonte está no GitHub.
Na primeira parte, criamos uma conta no Amazon AWS, o serviço de nuvem da Amazon, onde criaremos o nosso servidor virtual Jenkins.
Conheceremos agora algumas características que servidores no AWS possuem e tomaremos algumas decisões quanto às mesmas.
O serviço do AWS responsável pela criação e manutenção de servidores virtuais na nuvem chama-se EC2 (de Elastic Compute Cloud).
No Amazon EC2, um servidor virtual é chamado de Instância (Instance).
Precisamos conhecer uma série de características que instâncias EC2 possuem, de modo a adequà-las às nossas necessidades, permitindo que a instância possa cumprir o papel de um servidor Jenkins integrando projetos .NET.
Primeiramente, é necessário escolher um sistema operacional: Windows ou Linux.
Como o Jenkins pode ser instalado em ambos os sistemas operacionais, a escolha natural seria o Linux, pois o preço de uma instância Linux é mais barata na Amazon que uma instância Windows. No entanto, como faremos a integração contínua de um projeto .NET, a escolha vai depender de qual ferramenta será utilizada para construir (fazer o build) do projeto .NET.
No caso de projetos em Mono, uma vez que suas ferramentas de compilação estão disponíveis em várias plataformas, em tese seria possível utilizar um servidor Jenkins em Linux.
No nosso exemplo, vamos utilizar a ferramenta MSBuild, da Microsoft, para construir o projeto. Sendo assim, será necessário utilizar um servidor Windows.
Uma instância do Amazon EC2 com Windows Server 2008 R2 e Jenkins utiliza 21GB de disco e 622MB de RAM, conforme mostra a figura abaixo:
Sendo assim, o menor tipo de instância recomendado é a Instância Pequena, que vem com 1,7GB de RAM.
A Microinstância não é recomendada, pois possui apenas 613MB de RAM, a não ser que você esteja apenas fazendo uma experiência. Neste caso, você poderá usar a oferta gratuita da Amazon para criar uma microinstância. Este será o tipo utilizado neste tutorial.
Se o uso do Jenkins se tornar mais intenso, à medida em que mais tarefas e projetos forem sendo tratados por ele, é possível fazer um upgrade, alterando o tipo de instância.
Para alterar o tipo da instância, é necessário antes pará-la, para então mudar seu tipo e iniciá-la. É uma pequena indisponibilidade, em troca da total facilidade em trocar o tipo de instância para o que for mais adequado à sua demanda.
Caso não possa haver indisponibilidade, mesmo que por poucos minutos, você pode criar um snapshot da sua instância atual, criar uma nova instância do tipo desejado e utilizar o snapshot criado como base para a mesma. Quando a nova instância estiver no ar, verifique se está tudo funcionando direito e, caso esteja, reassocie o Elastic IP da instância antiga à nova e pronto! Você terá subido um novo servidor sem criar qualquer indisponibilidade aos usuários. Não esqueça de parar ou terminar a instância antiga, para não ficar pagando à toa.
Quando criamos um servidor virtual no Amazon EC2, é possível escolher em que local ele ficará.
Os servidores do Amazon EC2 ficam em vários data centers espalhados pelo mundo, agrupados em Regiões (Regions):
As regiões são independentes e a conectividade entre as mesmas é feita através da Internet, implicando em custos proporcionais ao volume de tráfego.
Normalmente, a escolha de uma região é feita: por questões técnicas, como por exemplo visando um melhor desempenho de conexão, devido à proximidade do servidor com seus usuários ou com outros servidores com os quais ele precisa se comunicar; ou por questões legais, como obedecer a alguma determinação de manter os dados de clientes no seu país de residência.
Um importante aspecto a ser notado é que um mesmo tipo de instância tem diferentes custos em difentes regiões. Consulte os preços ou a calculadora para ter uma estimativa de custos para seu projeto.
Cada região possui duas ou mais Zonas de Disponibilidade (Availability Zones):
As zonas de disponibilidade são agrupamentos de servidores estruturados de forma a, se uma determinada zona falhar, isto não afetará as demais zonas. Assim, é possível manter servidores diferentes em zonas distintas, de modo que, se houver problemas em uma zona de disponibilidade, os servidores na outra zona podem atender a demanda dos usuários até o problema ser resolvido.
Existe no EC2 uma rede de baixa latência que interconecta as zonas de disponibilidade de uma mesma região, permitindo a comunicação entre servidores em diferentes zonas.
No caso particular do nosso servidor Jenkins, deve-se ter em mente com quais outros computadores ele precisará se comunicar. Isto dependerá das atividades que o Jenkins será configurado para desempenhar.
Num projeto de aplicação web em que o Jenkins seja responsável tanto por fazer a integração contínua quanto a publicação da aplicação web em servidores de homologação e produção, teriámos resumidamente as seguintes comunicações:
Na figura acima, a grossura das setas mostra o volume estimado de tráfego, enquanto que o tom escuro indica uma maior frequência estimada no uso da conexão.
Caso estivéssemos utilizando um servidor de Git próprio e servidores web em uma região do EC2, manter o Jenkins na mesma região favoreceria as conexões frequentes e com grande volume, que utilizariam a rede de baixa latência, enquanto que as demais conexões usariam a Internet, mais lenta:
Quando se utiliza o GitHub como serviço, seu acesso de dará pela Internet de qualquer forma. Sendo assim, o servidor Jenkins ainda se beneficiaria se ficasse na mesma região dos servidores web:
Note que os cenários acima são fictícios. O mais importante é analisar o caso particular do seu projeto e fazer a melhor escolha possível dentro do que se conhece no momento.
No nosso caso, vamos utilizar a região da América do Sul, pela proximidade, porque podemos escolher livremente onde ficarão o Jenkins e, opcionalmente, servidores web e porque a diferença de custo para outras regiões não é significativa. Seremos indiferentes quanto à zona de disponibilidade, deixando a cargo do EC2 escolhê-la automaticamente.
Uma vez definidas as características da instância, faremos a seguir a definição dos grupos de segurança no EC2.
Nesta série de tutoriais, vamos criar um servidor Jenkins na nuvem, usando a Amazon AWS, e configurá-lo para fazer a integração contínua de um projeto .NET cujo código-fonte está no GitHub.
Você precisará de uma conta no AWS para criar seu servidor na nuvem da Amazon. Caso já possua uma, prossiga para o próximo tópico.
Para criar uma conta, siga os passos:
Preencha os campos de nome, endereço, captcha, marque o aceite do termo de cliente do Amazon AWS e clique no botão Create Account and Continue. Será exibida a página de cadastro de cartão de crédito:
Clique no botão Continue. Será exibida a página de confirmação de identidade por telefone:
Tecle no telefone o número do PIN informado. A mensagem automática irá confirmar a digitação do PIN e a página será atualizada automaticamente para confirmar o fim do processo:
Clique no botão Continue. Será exibida a página de confirmação do cadastro, dizendo que sua conta está sendo ativada:
Dentro de alguns minutos, você receberá uma mensagem de e-mail confirmando a criação da conta.
Uma vez que já possuímos uma conta no Amazon AWS, vamos acessar o console de administração, que dá acesso a todos os servidos oferecidos pelo Amazon AWS.
Caso seja solicitado, entre com suas credenciais (e-mail e senha).
Será exibida a página do Console de Gerenciamento do Amazon AWS:
Agora, podemos prosseguir definindo algumas características para o nosso servidor.
Um grande amigo que está desenvolvendo um site perguntou-me como habilitar o SSI no seu Windows 7 local. Eis o passo a passo, meu camarada:
O SSI (Server Side Include) é um recurso opcional do IIS (Internet Information Services / Serviço de Informações da Internet), que, por sua vez, é um serviço opcional do Windows 7.
No Windows 7 Professional, é necessário habilitar o IIS para usar a máquina local como servidor Web. Caso se queira utilizar o SSI, além do IIS, também é necessário habilitar esta funcionalidade.
Para habilitar IIS e SSI:
Note, na figura, que o Serviço de Informações da Internet está parcialmente marcado, pois ele possui um grande número de sub-recursos opcionais e é uma boa prática habilitar somente os recursos que se irá utilizar, para deixar o sistema mais leve e seguro.
Marque as opções e clique no botão OK.
Para testar o SSI, vamos criar uma página de teste, chamada teste-ssi.shtml, que exibirá a data atual e incluirá uma outra.
Note que utilizaremos a extensão .shtml para o arquivo. Por padrão, esta extensão está associada ao módulo que executa o server side include no IIS. Sendo assim, para que não seja necessário fazer configurações adicionais, utilize esta extensão em todas as páginas que possuem server side includes.
A página será criada no diretório do web site padrão do IIS local, no diretório c:\inetpub\wwwroot. Como este diretório é protegido pelo sistema operacional, será necessário executar o editor de código (neste exemplo, o Bloco de Notas) com privilégio de administrador.
<h1>TESTE DE SSI</h1> <h2><!--#echo var="DATE_LOCAL"--></h2> <!--#include file="teste-ssi-conteudo.html"-->
e salve o arquivo como c:\inetpub\wwwroot\teste-ssi.shtml, usando codificação UTF-8:
A primeira linha do código acima utilizará o recurso do SSI de variáveis de ambiente, para exibir a data atual. A segunda faz efetivamente um server side include, incluindo o conteúdo do arquivo teste-ssi-conteudo.shtml na página atual.
<h2>TESTE DE CONTEÚDO INCLUÍDO</h2>
e salve o arquivo como c:\inetpub\wwwroot\teste-ssi-conteudo.html, com codificação UTF-8.
http://localhost/teste-ssi.html
Você deverá visualizar a página de teste, exibindo a data e o conteúdo incluído:
Versão nerd (paródia) da letra da música “Assim Você Mata o Papai”, do Sorriso Maroto.
Acompanhe pelo áudio da música original.
using System;
namespace site_legado {
/// <summary>Versão nerd de "Assim Você Mata o Papai", por @sother.</summary>
public partial class Home : System.Web.UI.Page {
protected void Page_Load(object sender, EventArgs e) {
throw new Exception(
@"E ESSE BUG QUE NÃO SAI!
Não tem nada funcionando,
acho que tá dando pau
E eu já venho debugando já faz tempo...
e nada de achar... o bug!
Já enchi de breakpoint,
Tem um log atrás do outro,
Mas não acho o diabo do defeito...
Vou tentar comentar...
Eu fui só colocar, a mais
no form um campinho e pensei
""Isto não vai quebrar... Não vai!""
E assim, me danei
E a home não renderiza mais
Tenho que consertar!
Ou eu vou pra rua!
Ai, ai, ai ai ai ai, e esse bug que não sai
Ai, ai, ai ai ai, não mexo em legado nunca mais
Ai, ai, ai ai ai ai, e esse bug que não sai
Ai, ai, ai ai ai, como tava eu nem lembro mais
// 'nerd music' version by @sother");
}
}
}
Nerd Music Anterior: A Thread Comeu Toda a RAM.
Versão nerd (paródia) da letra da música “Vem ni mim, Dodge RAM”, de João Lucas e Marcelo.
Acompanhe pelo áudio da música original.
using System;
namespace AThreadComeuTodaARAM {
/// <summary>Versão nerd de "Vem ni mim, Dodge RAM", por @sother.</summary>
class Program {
static void Main(string[] args) {
Console.WriteLine(@"
A thread comeu toda a RAM. Só tem duzentos e oitenta
bytes. Com tão pouco, o Windows se arrebenta!
Não faço há muito tempo, nem um só teste sequer
Eu fico só programando e seja o que Deus quiser
Esse monte de warning não faz sentido pra mim
Um dia eu decidi: vou deixar tudo aqui
O tal de FxCop é um baita de um cachorro
Tem tanto sinal vermelho que eu até corro... de medo
Agora eu tô mudado. Fiquei de saco cheio.
Eu nem compilo mais: eu salvo, comitto e vai!
");
}
}
}
Nerd Music Seguinte: E Esse Bug Que Não Sai.
Nerd Music Anterior: Eu Quero Struct, Eu Quero Char.
Versão nerd (paródia) da letra da música “Eu Quero Tchu, Eu Quero Tcha”, de João Lucas e Marcelo.
Acompanhe pelo áudio da música original.
using System;
namespace EuQueroStructEuQueroChar {
struct EuQuero {
char _euQuero;
}
class Program {
static void Main(string[] args) {
Console.WriteLine(@"
Comecei o sprint, doidinho pra programar
A galera tá no clima, todo mundo quer codar
Meu par me chamou e disse - faz um struct char char
Perguntei o que é isso, ele disse - vou te ensinar
Fica tudo só na pilha, é um tipo de valor,
Não tem garbage collection, o runtime nem parou
Basta sair do método pra memória liberar
Então faz struct char char, o time inteiro vai comittar
Com o C# .NET
Eu quero struct, eu quero char
Eu quero struct char char, struct struct char
");
}
}
}
Nerd Music Seguinte: A Thread Comeu Toda a RAM.