Heroku foi – até onde eu me lembro – o primeiro PaaS (mainstream) no mercado. Era apenas Ruby, mas foi o símbolo do desenvolvimento da Web moderna na época, com todo o buzz de “faça o que precisa ser feito” e a mentalidade de “funciona perfeitamente” e tals.

Fiz alguns aplicativos Rails há algum tempo, e um deles foi o Travlr (que eu provavelmente deveria encerrar) e, mais recentemente, o Bieber.ly e sempre foi incrível trabalhar com isso. O Git faz o push do código, a sua implementação, instalação com um clique e arrastar para escalar. Nossa “parceria” não deu certo porque ele sempre funcionou com Ruby, e como eu também estava fazendo um monte de trabalho em PHP, obviamente queria que pudesse ter o mesmo para os meus outros projetos.

Então, o PHP-Fog (mais tarde rebatizado como App Fog) veio junto com o slogan “Heroku para PHP!”. Eu fiquei animado e comecei a usá-lo imediatamente, passando o meu site para lá e colocando alguns aplicativos simples de clientes novos lá, mas era muito cedo e não gerou grandes coisas. Foi tudo bem, mas não incrível. Escalonar, às vezes, leva um bom tempo e, essencialmente, apagaria o aplicativo e instalaria uma nova cópia, perdendo todos os dados temporários. Também não havia como fazer SSH, ou baixar ou ajustar qualquer coisa ou fazer qualquer outra coisa que você queria fazer. Enfim.

Orchestra.io surgiu, e o fundador Eamon Leonard fez a gentileza de me dar uma demonstração das primeiras versões. Mais uma vez, era cedo, mas não parecia fazer tanto quanto o PHP-Fog fez, o que já era menos do que eu queria.

O Pagodabox apareceu e ofereceu muito mais funcionalidades. Era incrível! Tinha escala instantânea de cima para baixo, tanto horizontal quanto verticalmente, ofereceu todos os tipos de opções de cache e tinha acesso SSH para que você pudesse fazer rsync em qualquer conteúdo gerado pelo usuário e fazer backups. (Sim, você deve usar S3 ou algo assim, mas tente dizer isso aos clientes usando a antiga porcaria chamada CMSs que não o suporta). O Pagodabox era incrível, então mudei meu site para ele, e coloquei alguns projetos simples de clientes lá.

O Heroku então começou a oferecer suporte oficial para Python, Node, Java, um monte de plataformas, mas não para o PHP. Quero dizer, você poderia até hackear, mas a plataforma era ruim e a configuração era uma combinação de comandos esquisitos. Era um cidadão marginal suportado somente por buildpacks de terceiros, como o incrivelmente bom CHH. Eu brinquei de leve com ele, mas continuei esperando o suporte para PHP antes de mudar algo substancial por lá.

Orchestra.io então foi adquirido por EngineYard, o maior concorrente do Heroku. Uau! Eu esperava que Heroku seguiria, então, para o PHP, mas não. Mas ainda temos essas três outras opções para brincar. Certo?

Com essas opções disponíveis eu, otimista que sou, chamei 2012 de “O Ano do PHP Cloud Hosting”. Até o final do ano, eu estava me considerando um idiota por ter pensado que isso poderia ter sido feito corretamente.

O Pagodabox era o mais completo em termos de recursos, mas nada estável. O PHP-Fog deixou de fazer o trabalho assim que o App Fog apareceu, mas faltavam algumas características cruciais no App Fog. Outras opções iam e vinham no espaço de poucos meses e outras estavam sempre disponíveis, mas eram ruins.

Parecia que muitas dessas empresas estavam fazendo essas plataformas por fazer, e sem entender o problema adequadamente.

O Fortrabbit foi o salvador para o ano passado e um grande sucesso na comunidade Laravel, mas infelizmente não tem tanto addons e, comparado com outras soluções de hospedagem, ele se tornou um tanto quanto caro.

A única vez que eu comecei a usar Heroku recentemente de forma correta foi quando Zack e eu construímos madeinproduction.com com Python/Flask. Eu ainda sinto falta dele.

Aí, adivinha o que aconteceu?

O HEROKU FOI LÁ E FEZ!

Heroku contratou David Zuelke para ajudar a trazer o PHP para a plataforma como uma linguagem oficialmente suportada. Eu já tinha visto bastante o nome dele no GitHub durante o trabalho com o buildpack CHH e alguns outros projetos, e eu sabia que seria um bom sinal. Poucos meses depois, houve uma versão beta privada, e agora o PHP é beta público no Heroku!

Bom, eu levei mais tempo para escrever este artigo do que para migrar esse blog baseado em PyroCMS para Heroku.

O PyroCMS 2.2 está um pouco defasado e só suporta MySQL. Porém, felizmente, a versão 2.3 será lançada em breve com suporte para PostgreSQL e SQLite também. Mas nesse meio tempo eu adicionei o addon ClearDB MySQL, e ele está pronto e funcionando. E isso levou, literalmente, cerca de 10 minutos.

Criei o aplicativo no Heroku por meio de sua interface web. Foi preciso que eu associasse a minha base de código local a um aplicativo Heroku.

$ git remote add heroku git@heroku.com:philsturgeon.git

Logado no Heroku na linha de comando. Se você não tem o aplicativo de linha de comando, vai querer instalá-lo.

$ heroku login

Pegue uma chave SSH para adicionar à sua conta (nem tem que esperar 5-15 minutos como a maioria dos outros sistemas PHP PaaS! Este é instantâneo).

Adicionei uma base dados (de graça, até 5mb).

$ heroku addons:add clearedb

Atualizei o meu system/cms/database.php para usar a variável ENV que eles configuraram apontando para o banco de dados. Faça o seu próprio system/cms/development/database.php substituir esse com a configuração do seu MySQL local.

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');

$url = parse_url(getenv("CLEARDB_DATABASE_URL"));

// Staging and Production
$db['default'] = array(
    'hostname'      =>  $url["host"],
    'username'      =>  $url["user"],
    'password'      =>  $url["pass"],
    'database'      =>  substr($url["path"], 1),
    'dbdriver'      =>  'mysqli',
    'activer'      =>  true,
    'pconnect'      =>  false,
    'dbdebug'      =>  true,
    'cacheon'      =>  false,
    'charset'      =>  'utf8',
    'dbcollat'      =>  'utf8unicodeci',
);

// Assign the group to be used $active_group = 'default';

Eles precisam de um composer.json lá e o PyroCMS 2.2 não tem um (o PyroCMS 2.3 tem).

$ touch composer.json && git add composer.json

Defina o PYRO_ENV para ser produção, para que ele não tente usar a configuração de desenvolvimento.

$ heroku config:set PYRO_ENV='production'

Leve todas essas coisas para o Heroku.

$ git commit -am "Added all the heroku-related changes" $ git push heroku master

TCHARAM! Pronto!

O meu site em PyroCMS 2.2 está agora rodando no Heroku. Eu finalmente comecei a verificar a minha lista de afazeres.

Ainda estão na lista:

• Atualizar para o 2.3.0-beta1, logo que for lançado
• Converter para PostgreSQL por causa da sua escala web
• Relatar sobre tudo isso corretamente em um artigo

O Heroku é uma solução incrível, porque eles não só entendem corretamente o problema, mas vêm fazendo isso há anos. Eles estão por aí desde 2007, compreendendo completamente como configurar hospedagem simples, de sites básicos até mais complexos como o The Twelve Fator App, que, se formos honestos, está se tornando cada vez mais comum nos dias de hoje, especialmente com todas essas pessoas por aí dizendo para você construir aplicativos API-first e API-centric … cof cof.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://philsturgeon.uk/blog/2014/05/heroku-and-php-sitting-in-a-tree