Tutorial – deploy com git no Ubuntu Server (AWS EC2)

Semana passada configurei um servidor novo para um cliente (GS Solutions) e optamos por usar AWS para este projeto (leia meu comparativo entre Locaweb e Amazon) e fiquei encarregado de configurar o servidor.

O servidor será exclusivo para um projeto e optei por fazer todos os deploys com git para manter o controle do código que vai para o ar e automatizar o deploy. 

Já fiz isso para o And After e para o Eu Compraria e lembro que foi um pouco complicado permitir o git pull através do apache (usuário www-data no Ubuntu Server).

Mas uma vez feito, não tem erro. este é um tutorial de 4 passos simples para configurar seu servidor e permitir deploy utilizando o Git.

O tutorial foi testado em servidor Linux (Ubuntu Server) e pode precisar de ajustes simples para outros servidores.

1. Instale o git no servidor

Sem nenhum mistério:

sudo apt-get install git

2. Crie uma chave para o user www-data

Aqui está o segredo de permitir o deploy diretamente por comandos do Apache, que utiliza o usuário www-data.

No meu caso o deploy é feito através de um ambiente fechado do sistema, onde através do PHP o git pull é executado. O repositório em questão será onde está configurado o domínio do serviço, então quando o pull é executado na branch master acontece o deploy.

Para criar uma chave ssh para o user www-data você vai precisar executar o ssh-keygen com este usuário, para isso execute no servidor:

sudo -u www-data ssh-keygen

E gere uma chave para este usuário, com ou sem senha. Na home deste usuáriuo (no Ubuntu Server a home do usuário www-data normalmente é /var/www/) você terá uma pasta .ssh onde ficarão as chaves.

3. Libere as chaves no seu repositório

Agora é só cadastrar as chaves no seu repositório para que seu www-data do servidor tenha acesso ao repositório, no terminal do servidor digite:

vi ~/var/www/.ssh/id_rsa.pub

Cadastre a chave pública no seu repositório e pronto, você está pronto para acessar seu repositório diretamente do seu servidor.

4. Clone o repositório

Agora no seu servidor você pode executar os comandos do git com o usuário www-data, por exemplo:

sudo -u www-data git clone meurepositorio.git

Lembre-se que para automatizar o seu deploy o domínio configurado no Apache (sites available) deve ser o seu próprio repositório.

Para fazer o deploy você pode escolher a forma que achar melhor. Eu executo os comandos com a ajuda do PHP em um ambiente fechado: assim o php (www-data) executa o git pull no repositório do seridor.

Não sei se existe (e qual é) o risco do user www-data ter uma chave pública cadastrada no repositório, mas o ideal é que este usuário tenha acesso apenas de leitura no seu repositório.

Leia também mais algumas dicas e utilidades para seu servidor:

Web Workers FTW!

Como todos sabemos, paralelismo sempre foi um problema quando estamos falando de JavaScript. Porém, com a Web Workers API a situação muda. Vamos conhecer essa oitava maravilha do mundo!

Imagine a seguinte situação: uma página onde você carrega um plugin de slideshow, autenticação com Facebook e load de dados através de JavaScript, entre outra carralhada de arquivos. Comum, certo? Agora me diga, quantas vezes você teve problema com botões que não respondiam aos seus eventos? Nenhum? Ok. Quantas vezes essa aplicação gerou um crash no navegador?

Se você já enfrentou os problemas que citei acima, keep calm, você não está 100% errado. Cada vez mais, nós desenvolvedores, estamos fazendo aplicações que exigem trabalho pesado usando JavaScript. Pensando nisso, eis que surge a oitava maravilha do mundo, Web Workers API, que usa mais de um processo para executar tarefas JavaScript paralelamente.

O que é paralelismo

Vamos à uma rápida explicação. Caso você já esteja ligado no assunto, pule para o próximo tópico.

Paralelismo, ou melhor, Programação Paralela, é a forma com que conseguimos fazer um algoritmo executar diversas tarefas usando mais de um processo, thread, ou no nosso caso, workers! Tudo isso com o intuito de ganhar mais performance. Não entendeu? Beleza. Uma imagem fala mais do que mil palavras:

Web Workers, como funciona

Se interessou por Programação Paralela? Ainda não entendeu? Aí vai uma boa referência: https://computing.llnl.gov/tutorials/parallel_comp/.

Como funciona

Atualmente é possível executar eventos de forma assíncrona usando setTimeout(), setInterval(), XMLHttpRequest entre outros hacks (ok, chutem-me). Porém, isso não quer dizer que é paralelo, sendo que os eventos são executados quando o script é renderizado.

Web Workers trabalham de forma diferente. E melhor. Como JavaScript não é uma linguagem que usa multi-threads, os Workers de certa forma “estendem-a” em alguns casos, possibilitando executar tarefas com mais uma thread. A API define que processos serão executados de forma assíncrona em outro contexto, por scripts que se comunicam através de mensagens que são passadas pelo método postMessage().

Mãos à obra

Para não sair da tradição (risos), vamos à um “Hello World”.

Como Web Workers executam paralelamente de forma isolada ao processo principal, vamos criar um novo arquivo que receberá a “ordem” desse processo e executará sua função. No nosso exemplo, chamei de worker.js e possui a função abaixo:

// recebe a mensagem do processo principal
onmessage = function(event) {
  var message = event.data;
  var result = message + ' no And After!';
  postMessage(result);
}

Feito isso, vamos criá-lo no processo principal:

var myWorker = new Worker('worker.js');

Para passar nossa informação, precisamos do método postMessage():

var message = 'Web Workers';
myWorker.postMessage(message);

E para finalizar, precisamos receber a mensagem do Worker:

// Recebe a mensagem do worker
myWorker.onmessage = function(event) {
  alert(event.data);
};

Se não quiser fazer na mão, é só baixar o exemplo aqui. Ou, você pode ver uns exemplos nesse link.

PS: isso não vai rodar localmente por restrições dos browsers modernos. Então, para aproveitar a trégua, aproveito para explicar que, como workers são arquivos externos, não será possível carregá-lo através de scripts que começaram com http:. Para ver esse exemplo funcionando, clique aqui.

Leia mais sobre segurança em http://www.html5rocks.com/en/tutorials/workers/basics/#toc-security

Talvez você esteja pensando “porr*, pra quê tanta enrolação para escrever uma mensagem na tela?”. Calma lá. Web Workers servem para auxiliar em tarefas porradas, como renderização 3D, cálculos que exigem mais desempenho, etc.

Importante: caso você não tenha percebido, o nosso exemplo não acessa o DOM diretamente. Web Workers não tem acesso ao DOM!

Além do DOM, Web Workers não tem acesso aos objetos window, document e parent. Mas calma, apesar disso, Web Workers tem acesso aos seguintes recursos do JavaScript:

  • navigator com quatro propriedades: appName, appVersion, userAgent e platform.
  • location (somente leitura)
  • self, que aponta para o objeto worker global
  • importScripts() para fazer load de um JavaScript externo
  • todos os objetos do JavaScript, como Object, Array, Math, etc
  • XMLHttpRequest
  • setTimeout()/clearTimeout() e setInterval()/clearInterval()
  • há também um método close() usado parar um Worker

Conclusão

Web Workers é algo novo, logo, a API pode mudar a qualquer hora, e pra melhor. Acredito que eles irão além do browser. Isso é só o começo, e já é demais!

Referências:

App nativa ou web app?

Uma das primeiras decisões que um time tem que passar no desenvolvimento de aplicativos mobile é se irão desenvolver um aplicativo nativo ou se irão desenvolver um aplicativo web para manter apenas uma versão para diversos dispositivos.

É uma decisão que pode ser bem complexa e a resposta mais correta depende muito das necessidades do seu aplicativo, do seu público e do time disponível. A apresentação abaixo mostra alguns pontos interessantes que podem influenciar na decisão.

[slideshare id=16148972&doc=appceleratorhtml5prezfinal-130123232125-phpapp02]

E como sempre, vale lembrar que não existe “bala de prata”.