Luciano Sother

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.

O que é um Key Pair do EC2?

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.

Criando uma nova instância Windows no EC2

1. Acesse a página do EC2:

   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).

2. No menu de navegação à esquerda, na seção INSTANCES, clique em Instances:

   Será exibida a página de Instâncias, com o painel My Instances mostrando que nenhuma instância foi criada ainda:

3. Clique no botão Launch Instance:

   Será exibida a janela Create a New Instance:

4. Clique na opção Quick Launch Wizard. Será exibida sua primeira página:

5. Para criar e fazer o download do arquivo com o par de chaves, no campo Choose a Key Pair:
   1. Digite um nome para o arquivo no campo Name (por exemplo, MeuParDeChavesDoAmazonEC2).
   2. Clique no botão Download:

      Aguarde alguns segundos enquanto o arquivo é preparado e então seu download ocorrerá automaticamente.

      O nome do arquivo será o nome que forneceu no passo anterior, com a extensão .pem:

6. No campo Name Your Instance, preencha Jenkins como nome da instância.
7. Na lista Choose a Launch Configuration, selecione a opção Microsoft Windows Server 2008 Base, e marque a opção 64 bit.
8. Clique no botão Continue:

   Será exibido um resumo com as informações da instância.

9. Clique no botão Edit details:

   Será exibida uma lista de seções de configurações, com a seção Instance Details aberta.

10. Marque o campo Termination Protection, para evitar que a instância seja terminada (perdida) inadvertidamente:

11. Clique no título da seção Security Settings para expandi-la. Note que o único grupo de segurança selecionadao é todos-os-servidores:

12. Pressione a tecla Control e, sem soltá-la, clique no grupo jenkins para também selecioná-lo:

13. Clique no botão Save details:

    Voltará a ser exibido o resumo das informações da instância.

14. Clique no botão Launch:

    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:

15. Clique no botão Close.

    Voltará a ser exibido o painel My Instances, mostrando a instância Jenkins, recém criada, com estado (coluna state) running (executando).

Criando uma nova instância Windows no EC2

Uma vez que a instância esteja executando, já podemos fazer uma conexão remota à mesma usando o Terminal Services.

1. No painel My Instances, clique com o botão direito na instância Jenkins e selecione a opção Connect:

   Será exibido o diálogo Console Connect – Remote Desktop Connection:

2. Clique em Download shortcut file, que irá fazer o download de um conveniente atalho para conexão à instância por Terminal Services (arquivo com extensão .rdp):

3. Precisamos obter a senha de administrador. Para isso, clique em Retrieve Password ou Retrieve Windows Administrator password.

   Será solicitado que você forneça o par de chaves criado anteriormente, para descriptografar a senha do administrador:

4. Clique no botão Escolher arquivo e selecione o arquivo .pem (no exemplo, MeuParDeChavesDoAmazonEC2.pem) criado anteriormente.

   Após selecionar o arquivo, o conteúdo da chave privada aparecerá na caixa de texto, abaixo de Private Key contents.

5. Clique no botão Decrypt Password:

   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.

6. Execute o atalho (arquivo .rdp) baixado anteriormente.

   Uma janela da Conexão da Área de Trabalho Remota (Remote Desktop) será exibida, alertando sobre a conexão que estamos prestes a fazer.

7. Clique no botão Conectar:

   Serão solicitadas as suas credenciais (usuário e senha):

8. Deixe o usuário Administrator selecionado, entre com a senha anotada anteriormente e clique no botão OK:

   Será iniciada a tentativa de conexão remota com o servidor:

   Será exibido um diálogo, alertando para a identidade do servidor remoto.

9. Ignore o alerta, marcando a opção Não perguntar mais sobre conexões com este computador e clicando no botão Sim:

   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.

10. Clique no local de rede Work (Trabalho):

    O resumo sobre a opção escolhida é exibida.

11. Clique no botão Close:

12. Clique no menu Start (Iniciar) / Windows Security (Segurança do Windows):

13. Clique em Change a password… (Alterar uma Senha…):

14. Entre a senha atual do administrador (anotada anteriormente) no campo Old password (senha antiga) e escolha uma nova senha, o mais segura possível, preenchendo-a nos campos New password (nova senha) e Confirm password (confirme a senha), clicando na seta ao final:

    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.

Acessando o Amazon EC2

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.

Selecionando a região da América do Sul

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.

Criando os grupos de segurança

Como vimos no artigo anterior, vamos criar os grupos todos-os-servidores e jenkins.

1. No painel My Resources, note que já existe um grupo de segurança criado. Clique no link 1 Security Group:

   Será exibida a página de Grupos de Segurança, exibindo o grupo default, criado automaticamente:

2. Clique no botão Create Security Group:

   Será exibida a caixa de diálogo Create Security Group.

3. Preencha o campo Name com todos-os-servidores e o campo Description com Todos os servidores.
4. Clique no botão Yes, Create:

   O grupo todos-os-servidores aparecerá criado na lista:

5. Clique no botão Create Security Group:
6. Preencha o campo Name com jenkins e o campo Description com Servidor Jenkins.
7. Clique no botão Yes, Create:

   O grupo jenkins aparecerá criado na lista:

Criando a regra de acesso por Terminal Services (RDP) à instância EC2

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.

1. Clique no nome do grupo todos-os-servidores. Note que os dados do grupo selecionado são exibidos no painel abaixo da lista:

2. Vamos agora configurar a permissão, que aqui é chamada de rule (regra) de controle de acesso.

   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:

3. No campo Create a new rule, selecione Custom TCP rule, especifique no campo Port range a porta 3389 e, no campo Source, o endereço IP do seu computador, atentando para o /32 no final.

   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).

4. Para que as novas regras sejam efetivadas, clique no botão Apply Rule Changes:

   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.

Criando a regra de acesso à interface web do Jenkins por HTTP à instância EC2

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.

1. Clique no nome do grupo jenkins.
2. Adicione uma nova regra para liberar o acesso à porta TCP 80 a partir do endereço IP do seu computador. Ao invés de especificar a porta, você também pode selecionar o tipo de regra HTTP, que é equivalente:

   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.

Definindo grupos de segurança no EC2

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:

• Instâncias pertencem a um ou mais grupos de segurança.
• Grupos de segurança definem um conjunto de permissões.

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.

Escolhendo o sistema operacional para o servidor Jenkins

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.

Escolhendo o tipo de instância EC2 para o servidor Jenkins

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.

É possível alterar depois o tipo de instância para um mais potente?

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.

Escolhendo um local para uma instância EC2

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.

Escolhendo um local para o servidor Jenkins

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.

Criação de Conta no AWS – Amazon Web Services

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:

1. Acesse o site do Amazon AWS, no endereço http://aws.amazon.com/pt/:

2. Clique no botão Cadastrar-se. Será exibida a página de login:

3. Preeencha seu e-mail, marque a opção I am a new user e clique no botão Sign in using our secure server. Será exibida a primeira página de cadastro:

4. Preencha nome, e-mail e senha e clique no botão Continue. Será exibida a segunda página de cadastro:

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:

5. Preencha os dados do seu cartão de crédito. Não se preocupe, pois a Amazon só cobrará ao final do mês pelo uso que você fizer dos serviços. Caso você só esteja seguindo este tutorial, o uso será da ordem de minutos e o custo será gratuito ou irrisório.

   Clique no botão Continue. Será exibida a página de confirmação de identidade por telefone:

6. Nesta página, a Amazon verificará seu número de telefone por um processo interativo. Preencha seu número de telefone e clique no botão Call me now. Será gerado um número de PIN. Em seguida, será feita uma chamada telefônica para o número informado, e uma mensagem automática irá pedir para discar no telefone o número de PIN:

   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.

Acessando o Console de Administração do Amazon AWS

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.

1. Acesse o Console AWS. Sugiro colocar este link nos favoritos do browser, arrastando-o e soltando-o na barra de favoritos/bookmarks do seu browser, para agilizar futuros acessos.

   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:

Habilitando o IIS e o SSI

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:

1. No Windows, tecle [WINDOWS] + [R] (ou clique no menu Iniciar / Executar) e execute o comando optionalfeatures:

   
   

2. Na caixa de diálogo Recursos do Windows, tanto o recurso IIS (Serviço de Informações da Internet), quanto o Server-Side Includes, devem estar marcados:

   
   

   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.

3. Dependendo da seleção de recursos, o Windows apresentará uma mensagem, indicando o progresso da instalação dos recursos selecionados:

   
   

Testando o SSI

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.

1. Tecle [Windows] (ou clique no menu Iniciar), digite o comando notepad e tecle [CONTROL] + [SHIFT] + [ENTER]. Usar esta combinação de teclas, ao invés de apenas teclar [ENTER] ou clicar no comando, fará o comando selecionado ser executado com privilégio de administrador:

   
   

2. No Bloco de Notas, entre com o código:

   <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.

3. Usando o Bloco de Notas, entre agora com o código:

   <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.

4. Agora, usando qualquer navegador Internet, acesse o endereço:

   http://localhost/teste-ssi.html

   Você deverá visualizar a página de teste, exibindo a data e o conteúdo incluído:

Referências

• Server Side Include
• Run a Command as Administrator from the Windows 7 / Vista Run box
• Run command for ‘Turn on or off Windows features’
• How can you take a screen shot of the Windows UAC prompt?

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.