Matheus Bratfisch Cogito ergo sum

Docker-compose com PHP-FPM, sendmail, nginx, mariadb serving jekyll e wordpress

Como expliquei recentemente, eu tinha um blog rodando no wordpress e decidi migrar para o Jekyll, mas existia um detalhe, eu não queria perder os links que já apontavam para o meu blog em wordpress, para atingir isso, Eu fiz o setup de um nginx o qual irá tentar encontrar arquivos estáticos do Jekyll e no caso de falha irá fazer um fallback para o wordpress.

Eu estava rodando os mesmos em uma instancia ec2 com RDS e o preço estava um pouco alto, então decidi mover tudo para uma unica máquina e utilizar o docker para poder mudar facilmente meu website de servidor.

Para atingir isso eu criei um docker-compose com:

  • PHP-FPM e sendmail para processar php e enviar e-mails com o sendmail
  • Nginx para servir arquivos estáticos e caso eles não sejam encontrados, servir meu antigo blog em wordpress
  • MariaDB como meu banco de dados para o wordpress
version: '3'
services:
  fpm:
    # image: php:7.0-fpm-alpine
    build: php7fpm
    restart: always
    volumes:
      - ./wordpress.matbra.com/:/var/www/wordpress.matbra.com
      - ./php7fpm/sendmail.mc:/usr/share/sendmail/cf/debian/sendmail.mc
      - ./php7fpm/gmail-auth.db:/etc/mail/authinfo/gmail-auth.db
    ports:
      - "9000:9000"
    links:
      - mariadb 
    hostname: test.com.br
  
  nginx:
    image: nginx:1.10.1-alpine
    restart: always
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/app.vhost:/etc/nginx/conf.d/default.conf
      - ./logs/nginx:/var/log/nginx
      - ./wordpress.matbra.com/:/var/www/wordpress.matbra.com
      - ./jekyll.matbra.com/:/var/www/jekyll.matbra.com
    ports:
      - "80:80"
      - "443:443"
    links:
      - fpm

  mariadb:
    image: mariadb
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=yourpassword
      - MYSQL_DATABASE=
    volumes:
    -   ./data/db:/var/lib/mysql

Container PHP-FPM:

Eu estou usando um Dockerfile modificado, o qual vem do php:7.0-fpm e adiciona sendmail e a extensão do mysql. Existe um script de inicialização modificado para rodar os dois serviços na mesma máquina. (Eu sei, eu deveria criar um container especifico para o sendmail)

Neste container eu estou mapeando alguns arquivos php e configurações:

  • ./wordpress.matbra.com para /var/www/wordpress.matbra.com meus arquivos do wordpress
  • ./php7fpm/sendmail.mc para /usr/share/sendmail/cf/debian/sendmail.mc meu arquivo de configuração para o sendmail
  • ./php7fpm/gmail-auth.db para /etc/mail/authinfo/gmail-auth.db meu arquivo de senha para o gmail Configuring gmail as relay to sendmail

Eu também estou mapeando as portas 9000 para 9000, então o nginx irá se comunicar com o php-fpm nestas portas e criando um link para o mariadb e criando um hostname

Container NGINX:

Eu estou usando um nginx alpine com alguns mapeamentos:

  • ./nginx/nginx.conf para /etc/nginx/nginx.conf meu arquivo de configuração para o nginx
  • ./nginx/app.vhost para /etc/nginx/conf.d/default.conf meu arquivo de configuração para o site com Jekyll fazendo fallback para o wordpress
  • ./logs/nginx para /var/log/nginx o diretório de logs
  • ./wordpress.matbra.com/ para /var/www/wordpress.matbra.com o local onde o nginx consegue encontrar meus arquivos do wordpress
  • ./jekyll.matbra.com/ para /var/www/jekyll.matbra.com o local onde o nginx consegue encontrar meus arquivos do jekyll

Eu também mapeio as portas 80 para 80 e 433 para 433, crio um link para o php-fpm para que o nginx se comunique com o container do php-fpm

Container MARIADB:

Sem mistérios aqui, uma imagem do mariadb com mapa para os dados e algumas variaveis de ambiente

Já que eu não adicione meus arquivos do website, eu criei um comando init.sh para remover o diretório de dados e clonar os mesmos do git. Também tem um comando chamado update-config.sh para atualizar as configurações do wordpress (wp-config.php) com os valores corretos.

Com isso eu consigo facilmente criar meu “sistema” em uma nova máquina.

https://github.com/x-warrior/blog-docker

Eu espero que seja útil. Matheus

Comment

Instale ZNC IRC Bouncer on AWS Linux

Se você quer instalar ZNC IRC Bouncer você vai precisar do CMake, porém a versão do CMake do AWS Linux é desatualizada. (Atualize seu cmake para 3.x)[http://www.matbra.com/2017/12/07/install-cmake-on-aws-linux.html]

Agora você precisa do git para clonar o código fonte do ZNC e também o openssl-devel para ter suporte ssl.

# yum install git openssl-devel

Clone o código fonte

$ git clone https://github.com/znc/znc.git

Entre na pasta

$ cd znc

Inicializa os submodulos

$ git submodule update --init --recursive

Instale

$ cmake . 
$ make
# make install (run this as root #)

Configure-o:

$ znc --makeconf

Atenciosamente, Matheus

Comment

Instalando Cmake 3 no AWS Linux

Se você está tentando compilar algo utilizando o CMake e tem o erro: “CMake 3.1 or higher is required. You are running version 2.8.12.2”

Você pode manualmente instalar a versão mais recente do CMake, para fazer isso. Eu removi o CMake existente.

# yum remove cmake

Teste se ele realmente foi removido

$ cmake 
-bash: /usr/bin/cmake: No such file or directory

Instale G++

# yum install gcc-c++

Baixe a ultima versão do: Cmake Download

$ wget https://cmake.org/files/v3.10/cmake-3.10.0.tar.gz

Extraia:

$ tar -xvzf cmake-3.10.0.tar.gz

Entre na pasta

$ cd cmake-3.10.0

Instale com

# ./bootstrap
# make
# make install

Agora você deve ter o cmake instalado /usr/local/bin/cmake

Abraços, Matheus

Comment

Loopback migrando seus models com o postgresql

Eu estou brincando com o Loopback, um framework javascript. Inicialmente eu só estava criando modelos e utilizando o explorer para verificar os resultados do mesmo, porém agora eu atingi um ponto que preciso persistir os dados.

Eu não consegui encontrar como manter meu banco de dados e meus modelos sincronizados facilmente, não tenho certeza se eu que não estou tão familiar com o Loopback ainda, ou se a documentação esta realmente um pouco confusa.

Então para criar um script que mantenha seus modelos sincronizados você pode criar um arquivo na pasta bin e nomea-lo autoupdate.js e adicionar o seguinte:

var path = require('path');

var app = require(path.resolve(__dirname, '../server/server'));
var ds = app.datasources.db;
ds.autoupdate(function(err) {
  if (err) throw err;
  ds.disconnect();
});

O código é bem simples, ele vai importar seu app do server.js, adicionar o datasource e rodar o comando autoupdate. Você poderia usar automigrate mas este limpa o seu database todas as vezes, então se você quer manter seus dados, essa não é a maneira apropriada.

Eu acredito que isso vai funcionar para outros bancos de dados, como MySQL. Se não funcionar, me avise, eu posso tentar ajudar.

Matheus

PS: Ele não vai fazer uma gerencia como o Django faz pra você, então as vezes você pode cair em estados indesejáveis, acredito que o ideal seria utilizar loopback com NoSQL

Comment

Django Storages com Boto3 e Metadados adicionais somente para as Medias

Eu tenho um projeto pessoal o qual estou usando Django com django-storages para enviar meus arquivos estáticos e medias para a Amazon S3, já que as minhas medias possuem UUID e não são editáveis eu gostaria de ter um tempo de expiração maior para elas, assim eu poderia salvar transferência porém eu não gostaria de ter essa cache maior para os arquivos estáticos que são atualizados com mais frequência.

Maioria dos conteúdos que encontrei na internet se referiam a AWS_HEADERS porém o mesmo não funcionou para mim. Parece que o mesmo só funciona para o boto (não para o boto3) e depois de olhar o código do boto3 eu descobri o AWS_S3_OBJECT_PARAMETERS o qual funciona para o boto3, mas esta é uma configuração global então eu precisei extender a classe S3Boto3Storage.

Então o código que resolveu meu problema foi:

class MediaRootS3Boto3Storage(S3Boto3Storage):
    location = 'media'
    object_parameters = {
        'CacheControl': 'max-age=604800'
    }

Se você está usando o boto (não o boto3) e gostaria de ter meta dados especiais somente para a sua classe Media, você pode usar:

class MediaRootS3Boto3Storage(S3BotoStorage):
    location = 'media'
    headers = {
        'CacheControl': 'max-age=604800'
    }

Você também vai precisar atualizar a sua configuração do django-storages, preste atenção ao nome da classe, no boto 3 é S3Boto3Storage porém no boto, o mesmo não possui o 3 depois da palavra Boto

DEFAULT_FILE_STORAGE = 'package.module.MediaRootS3Boto3Storage'

Uma dica simples, porém pode salvar um pouco do seu tempo.

Matheus

Comment

Redirecionar acessos para um servidor Wordpress secundário usando Nginx

Alguns de vocês provavelmente acompanhou, mas recentemente eu decidi atualizar meu antigo wordpress blog do PHP4~5 para um mais recente. Deixando meu host compartilhado e indo para o heroku e posteriormente para Amazon EC2.

Eu precisava decidir se eu manteria o Wordpress ou se eu mudaria para uma tecnologia diferente, como Jekyll? Ou o que? Eu pensei bastante sobre isso e no fim eu decidi utilizar Jekyll, por que? Para ser sincero, usando algo mais novo/recente me motiva a estudar e fuçar mais a fundo para conseguir as coisas rodando.

Depois que decidi que usaria o Jekyll, eu precisava pensar sobre meu dominio, eu queria manter meu blog antigo rodando como histórico mas também gostaria de fazer redirecionamento correto para não perder meus pontos de SEO por exemplo, então como manter 2 blogs funcionando de uma maneira inteligente sem quebrar os links antigos?

Eu pensei que o ideal seria algo que tentasse acessar o novo site e caso não encontrasse, deveria redirecionar para o blog antigo rodando Wordpress, mas como atingir isso somente quando a página não fosse encontrada e de uma maneira boa para SEO (utilizando 301 para os redirects)?

Depois de algum tempo brincando e lendo a documentação do nginx eu achei uma maneira de rodar um servidor com um proxy e caso o acesso falhe, interceptar o mesmo e redirecionar para outro servidor do nginx.

Então para fazer isso eu tenho um arquivo de configuração do nginx com multiplas configurações, a primeira delas possui a configuração do Wordpress, esse servidor é bem simples e somente trata acessos de páginas PHP com o PHP FPM basicamente usando um subdomínio.

server {
   listen 80;
   server_name wordpress.matbra.com;

    location / {
        root   /var/www/wordpress/live;
        index  index.php index.html index.htm;
        try_files $uri $uri/ /index.php?$uri$args;
    }

    location ~ \.php$ {
        root /var/www/wordpress/live;
        fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

Read more

Compilando seu site em Jekyll depois do git push

Se você quer compilar (buildar) o seu blog no seu próprio servidor depois de um git push, você pode usar os git hooks. Para fazer isso, você pode simplesmente extender a minha dica Deploy depois de push para também compilar o seu Jekyll como ambiente de produção. Para fazer isso basta adicionar o código abaixo depois do rm -rf

	cd $LIVE_PATH
	bundle install
	JEKYLL_ENV=production jekyll build

Matheus

Comment

Forçar www no endereço do seu Jekyll usando Javascript

Eu queria fazer meu site ter sempre a mesma url, com o prefixo www como meu Jekyll não possui um back-end eu não podia fazer no servidor, portanto eu precisava utilizar Javascript ou meta tags. Algumas pessoas comentam que o buscador do Google considera tags meta refresh como redirects (301/302) então essa solução seria a mais adequada.

Teimoso do jeito que sou, decidi utilizar Javascript. Se você desejar fazer com que o seu blog tenha esse mesmo comportamento, utilize o seguinte código:

<script>
if (window.location.hostname.indexOf("www") != 0) {
	window.location = window.location.protocol + "//www." + window.location.hostname + window.location.pathname;
}
</script>

Eu criei um arquivo _include/force_www.html e estou usando a variável jekyll.environment para incluir essa paret do template e ter esse comportamento somente no ambiente de produção.

Matheus

Comment

Definindo variáveis de ambiente para o PHP-FPM

Após instalar o nginx e o PHP, eu queria passar variáveis de ambiente para o PHP 7 para que eu não tivesse que salvar as configurações para o meu repositório.

Quando você utiliza variáveis de ambiente o ideal é defini-las sem deixa-las salvas, porém nesse caso eu salvei as mesmas.

Se você deseja adicionar variáveis de ambiente para o seu PHP-FPM, você pode editar /etc/php-fpm.d/www.conf (Estou fazendo isso no Amazon Linux e PHP 7.0)

Existe uma configuração no PHP-FPM, clear_env = no esta variável define se o PHP vai receber um ambiente limpo ou não. Eu deixei a mesma habilitada (o valor padrão é habilitado) mas adicionei as minhas variáveis de ambiente:

env[WP_SECURE_AUTH_KEY] = "valor1"
env[WP_NONCE_KEY] = "valor2"

Depois disso eu reiniciei o nginx e o PHP-FPM:

sudo service nginx restart
sudo service php-fpm restart

Matheus

Comment

Deploy depois de dar push com o seu git

Eu expliquei como enviar seu código para o seu próprio servidor e depois disso você talvez queira executar algumas ações específicas, no meu caso eu gostaria que meu blog fosse atualizado quando eu enviasse uma nova versão para o git então eu usei um `post-receive hook.

Este script vai manter as 3 últimas versões do seu código, então se algo der errado, você pode fazer rollback mudando o link. Para fazer isso o script utiliza a variável DEPLOY_PATH e cria uma nova pasta sources nela, a qual vai ter as versões do seu site. A versão ativa é basicamente um link simbolico (symlink) da pasta live para a pasta sources

Variáveis:

  • REPO_PATH = Caminho para o seu repositório local
  • DEPLOY_PATH = Caminho para a pasta de release
  • DEPLOY_BRANCH = Branch que você quer lançar
#!/bin/bash
REPO_PATH=/home/someuser/test.git
DEPLOY_PATH=/var/www/
DEPLOY_BRANCH="master"

echo "REPO_PATH=$REPO_PATH"
echo "DEPLOY_PATH=$DEPLOY_PATH"

while read oldrev newrev refname
do
    branch=$(git rev-parse --symbolic --abbrev-ref $refname)
    if [ $DEPLOY_BRANCH == "$branch" ]; then
        TIMESTAMP=$(date +%Y%m%d%H%M%S)
        VERSION_PATH=$DEPLOY_PATH/sources/$TIMESTAMP
        LIVE_PATH=$DEPLOY_PATH/live
        echo "TIMESTAMP=$TIMESTAMP"
        echo "VERSION_PATH=$VERSION_PATH"
        echo "LIVE_PATH=$LIVE_PATH"

        mkdir -p $VERSION_PATH
        mkdir -p $VERSION_PATH/sources

        git --work-tree=$VERSION_PATH --git-dir=$REPO_PATH checkout -f $DEPLOY_BRANCH
        # Remove git files
        rm -rf $VERSION_PATH.git
        rm -rf $LIVE_PATH
        ln -s $VERSION_PATH $LIVE_PATH


        # Delete old folder keeping the 3 most recent ones, which aren't the current live one, / (root, security measure, different from your source folder)
        rm -rf $(ls -1dt $(find -L $DEPLOY_PATH/sources/ -maxdepth 1 -type d ! -samefile / ! -samefile $DEPLOY_PATH/sources/ ! -samefile $LIVE_PATH -print) | tail -n+3)
    fi
done

Se você ainda tiver alguma questão me avise, Matheus

Comment