Configuração de um VPS no Google Cloud

Parte 1 – Criação da Instância

escrevo depois

Parte 2 – Configuração da Instância

Nesse ponto, quando o Google disser “OK”, o que nós temos? Uma instãncia Linux já executando, mas sem nada de útil ainda. A primeira coisa que precisamos é torná-la pública, através da vinculação de um IP externo estático, através do qual vamos acessá-la, primeiro por SSH, depois pelos serviços que ela vier a presta (site, por exemplo). Claro, você pode fazer toda a configuração sem o IP externo, usando o cliente SSH do próprio Google Cloud ou mesmo acessando pelo IP temporário que ele atribui a toda máquina. mas o IP estático tem lá suas vantagens, e a primeira delas tem a ver com DNS, sendo muito mais prático atribuir um domínio ao IP e vice-versa.

A segunda coisa que precisamos fazer é nos dar acesso ao servidor. A máquina já vem com um usuário “ubuntu” padrão, e o Google Cloud ainda cria um segundo usuário com o nome da conta Google, que ele usa para os acessos SSH via sua interface (console fornecido pelo Cloud). O que eu recomendo fazer é, se você usa Linux como máquina de trabalho, pegar a sua chave pessoal pública em ~/.ssh/id_rsa.pub e incluí-la na lista de chaves permitidas. Isso vai liberar o acesso à sua máquina com o seu nome de usuário local (é possível ajustar, caso precise, desde que antes de confirmar). Todos os usuários criados até agora são super-administradores (poder de sudo). Mais usuários podem ser criados e gerenciados pelo Linux normalmente. Lembrando que por default o SSH da instância não permite acesso por senha, somente por Chave Pública (liberar é possível, mas reduz a segurança do sistema).

A terceira coisa a se fazer é atualizar o sistema. Isso pode ser feito com um único mega-comando, no caso abaixo pensando numa pilha LAMP básica sem muita frescura:

sudo add-apt-repository ppa:certbot/certbot -y && sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get install -y language-pack-pt && sudo locale-gen && sudo dpkg-reconfigure tzdata && sudo apt-get install -y apache2 php mysql-server mysql-client php-cli php-gd phpmyadmin software-properties-common python-certbot-apache ssh vim zip unzip rar unrar wget curl nmap git subversion libapache2-mod-php php-mcrypt php-mysqlnd molly-guard

Alguns pontos sobre o comando acima:

  • CertBOT é o gerador automático e gratuito de certificados SSL. Para o Ubuntu a melhor forma de instalar é via um repositório PPA, que é seguro.
  • Atualizar a lista de pacotes e atualizar os existentes é um primeiro passo bem sensato.
  • Instalar o idioma português e configurar o fuso-horário do servidor, além de facilitar nosso uso, ainda elimina algumas possíveis mensagens chatas e confusões mais tarde.
  • A lista de programas inclui Apache (2.4) com PHP (7.0), MySQL (5.6), phpMyAdmin, versionadores de código e alguns utilitários que de vez em quando são úteis.
  • No processo, você deverá responder algumas perguntas, incluindo seu fuso-horário, senha de root para o MySQL, e configuração do phpMyAdmin, entre outros possivelmente.

Tem um passo nessa hora que eu gosto de executar, embora não afete em nada o servidor, mas facilita (pra mim) o uso dele. Editando o arquivo ~/.bash_profile podemos configurar um prompt colorido e talvez mais informativo, além de definir alguns atalhos úteis. Pode ser feito a nível de sistema via /etc/profile.d também, se quiser aplicar a todos os usuários.

#!/bin/bash
alias dir=’/bin/ls -lahF –color=auto’
alias grep=’/bin/grep –exclude-dir=.svn –exclude-dir=.git –color=auto’
alias grepi=’/bin/grep –exclude-dir=.svn –exclude-dir=.git –color=auto -i’
alias ls=’/bin/ls –color=auto’
alias dir=’/bin/ls -lhF –color=auto’
alias rm=’/bin/rm -i’
alias cp=’/bin/cp -i’
alias mv=’/bin/mv -i’
export PS1=”\[\e[35m\]\u\[\e[m\]@\h:[\W]\$ “

Agora a configuração passa para os dados hospedados e especificidades de serviços. Vai variar conforme a função do servidor. Outras coisas comuns que podem ser feitas:

  • Definir a senha do root (sudo passwd), já que a padrão aleatória (gestão orientada à sudo). Recomendo a mesma do root do MySQL.
  • Definir a senha do seu usuário (sudo passwd `whoami`), pelo mesmo motivo
  • Esconder, restringir ou mudar o ponto de acesso do phpMyAdmin, para aumentar a segurança
  • Instalar PHP-FPM ou suphp se o servidor tiver sites de mais de um cliente

Uma recomendação legal é criar 1 arquivo de configuração do Apache para cada domínio que tem ligação com o servidor. Inclusive para domínios de simples redirecionamento, que podemos gerar com um script simples:

export from=”dominio.com.br”; export to=”https://www.dominio.com.br/”; echo -e “<VirtualHost *:80>\n\tServerName $from\n\tDocumentRoot /var/www/html\n\tRedirectPermanent / $to\n</VirtualHost>” > /tmp/tmpdom && sudo mv /tmp/tmpdom /etc/apache2/sites-available/$from.conf && sudo a2ensite $from && sudo apachectl configtest && sudo service apache2 reload && sudo certbot –apache -d $from

O último comando da sequência acima usa o CertBOT para gerar um SSL, sendo que na primeira vez que é executado ele pede um e-mail e aceitação dos termos de uso. Sendo redirecionamentos, ao final escolha a opção (1) para não redirecionar, assim o destino final é alcançado sem hops intermediários. Para configurar domínios de uso real, é melhor ver com a sua aplicação.

Notas sobre instalação de uma aplicação Symfony3

Uma coisa interessante que eu quero muito experimentar é o Symfony3. Mas eu não tenho hoje o tempo disponível para ler tudo, testar, brincar e então experimentar de maneira metódica cada funcionalidade antes de criar uma primeira aplicação útil. Eu já fiz isso anos atrás com o Symfony 1.4, até comprei livro na época. Mas agora meu tempo para isso é muito menor, apesar da relevância do projeto que tenho em mente.

Então eu pensei: alguém já deve ter feito alguma aplicação inicial que eu possa clonar ou copiar e da qual eu possa derivar minha aplicação, de preferência já aproveitando toda a parte de controle de usuário, autenticação, dependências comuns, e quem sabe até uma interface administrativa? A boa notícia: sim, alguém já fez isso.

Eu encontrei na verdade 3 soluções, embora tenha vislumbrado algumas outras. A primeira é a mais óbvia: o projeto “demo” disponibilizado pelo próprio Symfony. É bem fácil de instalar e tem uma vantagem sobre as demais (pelo menos nos testes que eu fiz): ele simplesmente funciona. Seguir o tutorial de instalação é bem fácil, e você conclui ele em minutos com o Symfony Demo rodando perfeitamente na sua máquina. Daí pra frente, é implementar sua própria lógica e controllers.

A segunda opção foi a mais promissora, e é exatamente o que eu buscava: uma “aplicação esqueleto” para prototipação rápida de projetos pessoais já com as funcionalidades mais comuns implementadas, como Autenticação Google/FB, bootstrap e outras. Mas ou o projeto está bugado ou minha incompetência com o Symfony é maior que eu julgava, fato é que simplesmente não consegui fazer o projeto rodar. Você pode tentar a sorte, se conseguir me fala porque estou interessado.

Embora o Projeto Demo do Symonfy me parecesse bem legal (e certamente algo a ser analisado), eu queria algo que me deixasse mais na frente em meu projeto, e acho que o mais importante seria uma interface gráfica já no modo que eu queria. E eu encontrei algo que me atendesse, por incrível que pareça. O cara pegou o Symfony3 e incorporou o Gentelella, um desses temas de Admin moderninhos, que atende minhas necessidades. Pelo que li sobre o projeto, as coisas não funcionam, mas já bastam pra mim.

A odisséia de Instalação do Symfony3

A primeira coisa que eu preciso fazer então é instalar o projeto. Não sou muito adepto desses arcabouços moderninhos, então não entendo muito de Composer, Bower, Node.JS, Angular, etc. Mas entende de PHP, de infra-estrutura, de MVC e uma pancada de outras coisas, logo devo dar conta do recado. Mas uma decisão que tomei foi, temporariamente, não versionar o projeto. Sou bom com Subversion, mas de GIT só sei o básico, e não vejo ainda como ter um projeto meu versionado em sincronia com o GitHub do autor, logo achei mais sensato trabalhar sem versionamento próprio, e mais tarde jogar no Subversion para deployment.

Seguindo as instruções do autor, eu instalei o Composer e ele preparou tudo. Me deu uma pancada de sugestão de pacotes a serem usados, que eu registro aqui porque depois posso querer investigar:

paragonie/random_compat suggests installing ext-libsodium (Provides a modern crypto API that can be used to generate random bytes.)
symfony/polyfill-intl-icu suggests installing ext-intl (For best performance)
doctrine/doctrine-cache-bundle suggests installing symfony/security-acl (For using this bundle to cache ACLs)
phing/phing suggests installing pdepend/pdepend (PHP version of JDepend)
phing/phing suggests installing pear/archive_tar (Tar file management class)
phing/phing suggests installing pear/versioncontrol_git (A library that provides OO interface to handle Git repository)
phing/phing suggests installing pear/versioncontrol_svn (A simple OO-style interface for Subversion, the free/open-source version control system)
phing/phing suggests installing phpdocumentor/phpdocumentor (Documentation Generator for PHP)
phing/phing suggests installing phploc/phploc (A tool for quickly measuring the size of a PHP project)
phing/phing suggests installing phpmd/phpmd (PHP version of PMD tool)
phing/phing suggests installing sebastian/phpcpd (Copy/Paste Detector (CPD) for PHP code)
phing/phing suggests installing siad007/versioncontrol_hg (A library for interfacing with Mercurial repositories.)
phing/phing suggests installing tedivm/jshrink (Javascript Minifier built in PHP)
sensio/framework-extra-bundle suggests installing symfony/psr-http-message-bridge (To use the PSR-7 converters)
monolog/monolog suggests installing aws/aws-sdk-php (Allow sending log messages to AWS services like DynamoDB)
monolog/monolog suggests installing doctrine/couchdb (Allow sending log messages to a CouchDB server)
monolog/monolog suggests installing ext-amqp (Allow sending log messages to an AMQP server (1.0+ required))
monolog/monolog suggests installing ext-mongo (Allow sending log messages to a MongoDB server)
monolog/monolog suggests installing graylog2/gelf-php (Allow sending log messages to a GrayLog2 server)
monolog/monolog suggests installing mongodb/mongodb (Allow sending log messages to a MongoDB server via PHP Driver)
monolog/monolog suggests installing php-amqplib/php-amqplib (Allow sending log messages to an AMQP server using php-amqplib)
monolog/monolog suggests installing php-console/php-console (Allow sending log messages to Google Chrome)
monolog/monolog suggests installing rollbar/rollbar (Allow sending log messages to Rollbar)
monolog/monolog suggests installing ruflin/elastica (Allow sending log messages to an Elastic Search server)
monolog/monolog suggests installing sentry/sentry (Allow sending log messages to a Sentry server)
sebastian/global-state suggests installing ext-uopz (*)
phpunit/phpunit-mock-objects suggests installing ext-soap (*)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)

Mas eu errei o servidor SMTP na etapa de configuração, então apaguei tudo e fiz de novo. Dessa vez ele foi mais longe, cheguei a abrir a aplicação e fazer login, mas os assets não estavam lá, ficou tudo desconfigurado. Fui atrás de informações, achei alguns tickets já corrigidos sobre o mesmo problema e parece que é uma coisa local, provavelmente relacionada ao Bower (já ouvi, nunca comi). Então, ao que parece eu preciso de alguns pré-requisitos no Ubuntu para que a coisa possa rodar. Além do LAMP Stack padrão (outro assunto…) precisei também de instalar e executar:

sudo apt-get install composer npm nodejs-legacy
sudo npm install -g bower

O Composer parece que tá legal, o NPM também, mas o tal do NodeJS está em legacy, e achei inclusive referências de um PPA mais apropriado (mas eu prefiro me ater aos pacotes da distribuição, sempre que possível). Embora pareça ter funcionado, ao instalar o Bower eu recebi outra mensagem dizendo que o Bower morreu e que eu devia migrar para o Yarn. Nem sei ainda o que o Bower faz, que dirá o Yarn, mas vamos em frente, depois penso nisso.

Com tudo isso feito, procedo novamente à instalação, depois de apagar o banco de dados e recriar a pasta vazia:

composer create-project krzysiekpiasecki/gentelella . “dev-master”
composer setup
composer test
php bin/console fos:user:create –super-admin
php bin/console server:run 127.0.0.1:8080 –env=dev

Na configuração de SMTP, minha recomendação é informar os dados do MailTrap, assim nenhum e-mail indesejado é disparado por engano. Só precisei ajustar a configuração da porta, que o instalado não perguntou (2525 e não o padrão 25). Isso eu fiz acrescentando chamados no config.yml e os valores no parameters.yml, conforme documentação do Symfony.

Versionamento do código do Projeto com GIT

Versionamento de código é algo que eu levo muito a sério. Apesar de ser um fã do Subversion, o fato do Symfony estar no GitHub e o esqueleto que encontrei também (além de várias dependências) me sugerem que o GIT seria uma escolha mais prática. Fora que o Composer parece assumir o GIT como algo nativo, integrado. OK, vamos de GIT então. O instalador pergunta no final se desejo manter os arquivos de versionamento (disse que sim), mas esses arquivos são ligado ao GitHub do Gentelella, e não é isso o que eu tenho em mente. Logo, refiz o processo de instalação para incluir versionamento do meu projeto no BitBucket:

  1. Criar um repositório no BitBucket (claro, pode ser GitHub também, mas BitBucket aceita projetos privados)
  2. Clonar seu repositório numa pasta
  3. Mover o .git para um outro local temporário (por backup e porque o instalador só aceita pastas novas e/ou vazias)
  4. Rodar o instalador normalmente (se preferir, apenas o primeiro passo, que é o que importa pro versionamento)
  5. Pedir ao instalador para remover os arquivos de versionamento (ou excluir a pasta .git manualmente)
  6. Move de volta o .git salvo para a pasta
  7. Adicionar os arquivos no git (git add –all; já tem .gitignore preparadinho)
  8. Commitar os arquivos no BitBucket (git push)
  9. Seguir a vida…

Como bom usuário Linux eu criei alguns mega-comandos pra fazer exatamente isso. Para implantar o projeto no meu repositório:

rm -Rf projeto gitbkp && echo “DROP DATABASE IF EXISTS nome_banco;”|mysql && git clone https://[email protected]/seu/projeto projeto && mv projeto/.git gitbkp && composer create-project krzysiekpiasecki/gentelella projeto “dev-master” && cd projeto && git add –all && git commit -m “Instalação do código-fonte importado do Gentelella” && git push

Das remoções de pastas e bancos talvez você não precise, é que eu rodei esse processo umas quinhentas vezes para ter certeza de tudo e verificar os detalhes.

Uma vez concluído esses passos, efetivamente você terá um repositório seu com a cópia do código do Gentelella pronta para ser mexida. Para instalar o projeto em outra máquina, basta substituir o primeiro comando, para ao invés de “criar um projeto”, baixar e configurar o seu projeto:

git clone https://[email protected]/seu/projeto <pasta>
cd <pasta>
composer install
composer setup

Daí pra frente vai depender se você vai rodar a aplicação do zero (e nesse caso crie seu usuário como antes) ou se vai restaurar um backup da aplicação de outro contexto. A beleza da coisa é que o passo “composer install” baixou todo o código de terceiros, o “composer setup” configurou seus acessos locais de SQL e SMTP, e agora você pode simplesmente restaurar um Dump do MySQL e copiar os arquivos de upload para ter uma cópia do seu projeto totalmente funcional (pode precisar de mais coisas, dependendo do seu projeto).