Computando-Arte on Crimideias do caioau

Dockerfile: Hardening e boas práticas

Mon, 16 Feb 2026 10:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 28Jan2026

Dockerfile é tudo igual? Se a imagem está sendo buildada e a aplicação está rodando, posso mandar bala? Vamos ver nesse texto que não. Existem outras considerações a serem feitas, principalmente de segurança. Vamos nos debruçar para encontrar o Dockerfile mínimo contendo apenas o necessário para rodar nosso app em Python.

Foto de S. Laiba Ali, unsplash

Nosso exemplo: API em Python com Flask

Nesse texto vamos explorar bastante esse exemplo, que retorna um “Hello world” simples, e pra fazer uma graça um endpoint que retorna de volta o que foi enviado no caminho da url.

from flask import Flask

app = Flask(__name__)

@app.route("/hello")
def hello_default():
    return hello("")

@app.route("/hello/<string:hellomsg>")
def hello(hellomsg: str) -> str:
    res = "hello world!"
    if len(hellomsg) > 0:
        res = hellomsg
    return res

if __name__ == "__main__":
    app.run(host="0.0.0.0")

app.py

Pra quem quiser brincar com eles, todos os códigos e arquivos utilizados nesse texto estão disponíveis no seguinte repositório gitlab.com/caioau/caioau.gitlab.io

Junto do Dockerfile temos o nosso requirements.txt:

1
2

Flask~=3.1.2
gunicorn~=23.0.0

requirements.txt

Para quem não está familiarizado com a notação ~= estamos usando apontando para versão compatível, como as bibliotecas utilizam versionamento semântico (semver.org) vamos utilizar versões mais novas mas dentro do mesmo menor (minor), mas sem mudanças que quebrem as funcionalidades atuais. A linha Flask~=3.1.2 equivale a Flask>=3.1.2,Flask==3.1.*

Dockerfile v0

Com o código-fonte do nosso app, podemos seguir com o Dockerfile.

A fim de ajudar no debug do app, vamos incluir o vim e curl nas imagens.

FROM debian:bullseye

RUN apt-get update && \
    apt-get install -y \
    python3-pip python3-dev \
    build-essential \
    curl \
    vim

RUN apt-get clean && rm -rf /var/lib/apt/lists/*

WORKDIR /usr/src/app

COPY . /usr/src/app/

RUN pip3 install -r requirements.txt

RUN rm -rf ~/.cache/pip

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v0

O que está acontecendo? Utilizando uma imagem base do Debian, instalamos o Python com outros pacotes que fazem a compilação (build-essential e python3-dev). E daí na próxima instrução deletamos o índice do apt-get.

Mudamos a pasta de trabalho (WORKDIR) e copiamos o código-fonte da aplicação lá, instalamos as dependências da aplicação e similarmente com os índices do apt-get deletamos o cache do pip.

Por fim, configuramos o comando que sobe a aplicação, utilizando o gunicorn como servidor web Python.

Quando colocamos para rodar a imagem, a aplicação funciona \o/

Porém, além de outros problemas de que vamos falar logo, o tamanho da imagem: 570MB, tá bom pra você quase 600 megabytes por um simples hello world?

Fica até o final, porque ~~vai ter bolo~~ vamos reduzir o tamanho dessa imagem para 10x menor.

Observação: Nesse texto, quando estivermos falando do tamanho da imagem, estamos nos referindo ao tamanho sem compressão, ou seja, o valor reportado por docker image ls, ao passo que o tamanho que aparece na página WEB no dockerhub ou outros registries é o tamanho com compressão. Por exemplo, uma imagem de 522 MB sem compressão resulta em 192 MB com compressão.

Dissecando imagens com dive

A nossa primeira dica é usar o dive para “dissecar” a imagem. Uma vez carregada, conseguimos acompanhar como estão os arquivos, então podemos ir “caminhando” a partir da camada inicial até a final como os arquivos foram sendo alterados e dessa forma conseguimos mais facilmente visualizar o que está acontecendo e identificar pontos de melhoria.

Para instalar, basta baixar o binário do github: github.com/wagoodman/dive

Com ele instalado basta executar com o nome da imagem

Bora ver como o dive analisa nossa imagem? Carregando ele podemos o histórico das instruções do nosso Dockerfile, cada instrução gera uma camada e vamos caminhando nesse histórico. Como são muitos arquivos na imagem base, podemos mostrar apenas os arquivos modificados (pressionando Ctrl+U). Vamos retomar esse ponto importante, mas preste atenção na instrução COPY . . quais arquivos são copiados, além do código-fonte.

Com a imagem analisada percebemos dois erros: os índices do apt e o cache do pip não foram limpos, aumentando o tamanho da imagem final desnecessariamente. Isso aconteceu pois a deleção dos arquivos não está na mesma instrução (RUN) do que a criação deles, propagando para a próxima camada.

Repare no canto inferior esquerdo que a ferramenta dá algumas dicas de onde melhorar, para a imagem ficar mais eficiente.

Use dockerignore

O outro erro da nossa v0 foi que alguns arquivos sensíveis vazaram, em particular o arquivo .env com credenciais. Isso aconteceu pois quando copiamos os arquivos em COPY . . todos arquivos no contexto do docker são copiados.

Como resolver? Podemos colocar tudo o que podemos copiar no Docker dentro de uma pasta dedicada, mas teríamos que manter esse controle.

Uma solução mais robusta é utilizar o arquivo .dockerignore (documentação), que funciona de uma forma similar ao .gitignore, limitando a quais arquivos é permitido o acesso no contexto Docker.

# ignora tudo
*

# permite codigos fonte
!/src
!*.py
!requirements.txt
!entrypoint.sh

# especifico do python
**/__pycache__/
**/*.py[cod]
# C extensions
*.so
**/.ipynb_checkpoints/

.dockerignore

Acima temos um exemplo de dockerignore que resolve nosso problema, onde todos os arquivos são por padrão bloqueados, e então vamos criando exceções como arquivos de código-fonte.

Dockerfile v1

Com as lições aprendidas na versão anterior, bora arrumar os erros que encontramos?

FROM debian:bullseye

RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    python3-pip python3-dev python3-venv \
    build-essential \
    curl \
    vim && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/app

COPY --chown=python:python . /home/python/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-cache-dir -r requirements.txt

ENV PATH="/home/python/app/.venv/bin:$PATH" # "ativa" o venv

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v1

O que mudamos da versão anterior? Colocamos a deleção dos arquivos desnecessários na mesma instrução (no caso do pip install utilizamos a opção –no-cache-dir).

Também usamos um ambiente virtual (venv) para melhor lidar com as dependências Python.

E por fim, para não rodar como root, criamos um usuário não root e o utilizamos sempre que possível. Se atente que o pip install foi executado como não root.

E o tamanho? Apesar de só termos mexido no cache do pip e os índices, a nova imagem é tem 520MB , aproximadamente 50MB menor (~10%).

User não root basta?

Criamos um usuário não root e paramos de usar o root, mas isso basta? A resposta é não, pois caso a aplicação esteja comprometida, o ataque pode usar qualquer binário presente na imagem para realizar ações mal-intencionadas. Um excelente site explorando isso é o GTFOBins que mostra como fazer essas explorações para cada binário.

Outro argumento é o princípio do privilégio mínimo que dita que devemos apenas usar as permissões mínimas necessárias para o funcionamento dos nossos sistemas, caso contrário as permissões excedentes podem ser abusadas.

Bora para uma revisão rápida de permissão de arquivos no Linux? O octeto de permissão é definido pelas permissões (do mais significativo para menos) ler (Read), escrever (Write) e executar (eXecute). E temos esse octeto três vezes (da esquerda pra direita): Para o dono, para o grupo e para outros.

Bora para um exemplo:

O dono vai poder ler (4), escrever (2) e executar (1) -> 4 + 2 + 1 = 7
O grupo vai poder ler (4) e executar (1) -> 4 + 1 = 5
Por fim outros vão poder apenas ler (4) -> 4

Resultado: Executando chmod 754 vai gerar o resultado que queremos.

Até aí tudo bem, mas além desses 3 dígitos tem um quarto dígito, normalmente omitido, à esquerda que define mais um octeto o Suid , Guid e o Sticky Bit. Se a gente setar o suid no nosso exemplo anterior, a permissão que tínhamos 754 vira 4754 (adicionando o 4 à esquerda).

E o que faz esse suid? Quando setado o arquivo quando executado não é executado por quem executa, mas por quem é dono do arquivo, que tipicamente é o root, ou seja, qualquer usuário “vira root” (o sudo funciona assim).

commitstrip.com/en/2016/06/29/chmod-what/

Bora mostrar na prática?

FROM debian:bullseye

RUN cp /bin/bash /bin/bash-suid && chmod u+s /bin/bash-suid

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/

Dockerfile-setuid

No dockerfile acima criamos um novo bash chamado bash-uid, com a permissão suid, agora mesmo que estejamos rodando como um usuário não root, se invocado esse bash especial escalamos o privilégio para root.

Para desarmar essa possibilidade, suba o container com a opção no-new-privileges que efetivamente protege contra a escalação de privilégio.

demonstrando o setuid

Repare que quando executamos o bash especial efetivamente se tornamos root, porém com a opção no-new-privileges habilitada resolvemos o problema.

Para outras boas práticas de segurança para containers docker consulte a excelente cartilha da OWASP (comunidade que publica diversas boas práticas de segurança para aplicações web): OWASP Docker Security Cheat Sheet

Dockerfile v2: introduzindo multistage

Até então estamos instalando compiladores necessários para o pip install, utilizando o pacote build-essential, porém em tempo de execução os mesmos não são necessários, esse é o cenário que a funcionalidade do multi-stage do docker resolve.

O multi-stage acontece quando utilizamos a instrução FROM múltiplas vezes, criando estágios separados, tipicamente para o build e um estágio final utilizado em tempo de execução, dessa forma os artefatos resultantes do build são passados pro estágio final, e os compiladores e outras ferramentas do build são instalados apenas no estágio de build, resultando uma imagem final menor.

FROM python:3.13 AS builder

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/app

COPY --chown=python:python . /home/python/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-cache-dir -r requirements.txt

FROM python:3.13-slim AS runtime

RUN useradd -u 1000 -U -m --shell /bin/bash python

USER python

WORKDIR /home/python/app

COPY --chown=python:python --from=builder /home/python/app/ /home/python/app/

ENV PATH="/home/python/app/.venv/bin:$PATH"

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v2

Dessa vez optamos por usar as imagens oficiais do python, então não precisamos instalar o python em si e os compiladores que precisamos em tempo de build. Agora o grande pulo do gato do multi-stage, as imagens de build e runtime são diferentes, a de build (python:3.13) têm 1.1GB e a de runtime (python:3.13-slim) aproximadamente 10% do seu tamanho com 120MB.

Outra mudança na imagem base, até então estávamos usando a release bullseye do Debian, mas consultando o endoflife.date podemos ver que essa release perdeu suporte principal, agora com a imagem python a tag 3.13 aponta para a release corrente do stable do Debian. Além de usarmos a variante slim da imagem do debian, sempre que possível opte por essa opção.

Uma dica valiosa para sempre manter suas dependências atualizadas é utilizar o dependabot ou similares como o renovate, que periodicamente atualiza as dependências automaticamente abrindo um pull request com a atualização.

Como ficou o tamanho? Essa versão ficou com 130 MB, um quarto da nossa primeira versão.

Fazendo nosso app em Golang

Até agora estávamos usando Python no nosso app, porém para o próximo conceito de imagens distroless, usar uma linguagem compilada, em particular Go, pois ele permite a compilação estática, ou seja toda a aplicação fica “empacotada” em apenas um binário, sem precisar de outros arquivos/pacotes para que a nossa app funcione.

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "time"
)

func rootHandler(w http.ResponseWriter, req *http.Request) {
    log.Printf("%v", req)
    fmt.Fprintf(w, "hello world!\n")
}

func helloHandler(w http.ResponseWriter, req *http.Request) {
    log.Printf("%v", req)
    msg := req.PathValue("msg")
    fmt.Fprintf(w, "%s", msg+"\n")
}

func weatherHandler(w http.ResponseWriter, req *http.Request) {
    url := "https://wttr.in/?T&lang=pt-br"
    ua := "curl/8.5.0"
    log.Println("making a GET request to url=", url, "...")
    client := http.Client{ // set a request timeout
        Timeout: 20 * time.Second,
    }

    r, err := http.NewRequest("GET", url, nil)
    if err != nil {
        panic(err)
    }
    r.Header.Add("User-Agent", ua)

    resp, err := client.Do(r)
    if err != nil || resp.StatusCode != http.StatusOK {
        log.Println("making a GET request to url=", url, "Failed! Returning a 500")
        log.Println("err=", err)
        w.WriteHeader(500)
        fmt.Fprintf(w, "request failed!\n")
        return
    }
    defer resp.Body.Close()
    log.Println("making a GET request to url=", url, "Done! Response code=", resp.Status)

    written, err := io.Copy(w, resp.Body)
    if err != nil {
        log.Printf("Error writing response after %d bytes: %v", written, err)
    }

}

func main() {
    apiPort := "8000"

    http.HandleFunc("/", rootHandler)
    http.HandleFunc("/weather/", weatherHandler)
    http.HandleFunc("/hello/{msg}", helloHandler)

    log.Println("Listening on port=", apiPort)

    panic(http.ListenAndServe(":"+apiPort, nil))

}

app.go

Nosso app continua igual à versão em Python, mas agora temos um endpoint a mais que faz um request externo para o site wttr.in obter a previsão do tempo.

E como fica o nosso Dockerfile? Como Golang é uma linguagem compilada vamos mostrar nesse exemplo a funcionalidade do multi-stage ao extremo: Criando um container com apenas o binário da nossa app.

FROM golang:1.25 AS builder

RUN useradd -u 1000 -U -m --shell /bin/bash nonroot

USER nonroot

WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot . /home/nonroot/app

RUN CGO_ENABLED=0 go build -ldflags="-s -w" app

FROM scratch

COPY --from=builder /etc/passwd /etc/passwd
# truque pra rodar nonroot no scratch

COPY --from=builder /home/nonroot/app/app /usr/local/bin/

USER nonroot
EXPOSE 8000

ENTRYPOINT [ "app" ]

golang/Dockerfile-scratch

Como podemos ver, compilamos nosso app no estágio de build, usando uma imagem que contém os compiladores e outras ferramentas para gerar o nosso binário, e como estamos compilando estaticamente (usando opção CGO_ENABLED=0) apenas o nosso binário é necessário para a aplicação funcionar. E depois do estágio de build, o estágio final não está utilizando nenhuma imagem base (SCRATCH), ou seja, nossa imagem final vai conter apenas o binário do nosso app.

Para quem ficou curioso, essa imagem tem apenas 6 MB, ao passo que a imagem base de build (golang:1.25) tem 850MB.

Quem quiser se aprofundar em diminuir o tamanho do binário ainda mais dá pra usar o upx (github.com/upx/upx) que faz compressão de executáveis, que reduziu o tamanho para ~2MB. Porém, acho que não vale a pena adotar essa abordagem, pois o Docker já faz essa compressão quando faz o download das imagens, então usar o upx só vai fazer seu app demorar mais para inicializar.

Se subirmos o container, vemos que os endpoints “hello world” funcionam, mas o endpoint de previsão de tempo não, com o erro: “tls: failed to verify certificate: x509: certificate signed by unknown authority”. Não temos a cadeia de certificados

Essa foi a nossa deixa para falarmos do conceito de imagens distroless.

Imagens distroless (github.com/GoogleContainerTools/distroless) foram introduzidos pela Google, e a ideia é que as imagens base tem o mínimo necessário para rodar a aplicação, sem ter uma distribuição base como o debian por trás, ou seja não tem o apt para instalar pacotes ou shell, etc …

Quem tiver interesse no repositório oficial, tem exemplos para várias linguagens. O que é chato dessas imagens é que caso você precise adicionar algum pacote que a imagem base não tem você precisa aprender o sistema de build pouco intuitivo chamado Bazel.

No nosso caso a imagem base distroless é a gcr.io/distroless/static, ela tem apenas 2MB. Quais pacotes ela tem? Como não temos o apt, não vamos conseguir facilmente listar os pacotes.

Para resolver esse problema de identificar os pacotes vamos introduzir um conceito do Software Bill of materials (SBOM), é um “inventário” identificando todos os componentes presentes em um determinado artefato de software. Ele tem alguns formatos padrão, o mais difundido é o System Package Data Exchange (SPDX) , tipicamente representado em um arquivo json. Nesse arquivo teremos as versões de todos os componentes, suas licenças e por fim os relacionamentos (como dependências).

É uma boa prática gerar o SBOM junto ao build da imagem Docker, pois isso facilita demais auditorias de segurança, por exemplo, quando identificada uma vulnerabilidade em uma biblioteca que utilizamos, conseguimos facilmente encontrar se de fato estamos seguros ou onde precisamos atuar atualizando um pacote para uma versão não vulnerável.

Vamos gerar o nosso SBOM utilizando o syft (github.com/anchore/syft), nossa imagem tem os seguintes pacotes: a cadeia de certificados que precisamos e infos de fuso horários necessários para alguns apps.

Usando essa imagem como base no estágio final, nosso endpoint de previsão do tempo funciona \o/

endpoint weather funcioando \o/

Debugando imagens distroless

Uma das maiores dificuldades em utilizar as imagens mínimas distroless é a de fazer o debug das aplicações, por exemplo, rodar um debugger com breakpoints para investigar algum bug.

Vamos abordar duas formas de resolver isso, a primeira é ter duas versões do Dockerfile, uma mínima utilizada em produção e uma versão “desenvolvedor” que inclui um shell, o gerenciador de pacotes como o apt e outros pacotes para esse fim.

Outra abordagem é “anexar” um container de debug junto ao container da aplicação, também chamado de container sidecar, o container de debug tem um shell e as ferramentas necessárias para fazer o debug e atua lado-a-lado da aplicação rodando.

Bora ver os pacotes da aplicação? Subi nosso app Golang com um container chamado golang, então vamos subir outro container usando o mesmo namespace de processos (pid) e na mesma rede, conforme o comando abaixo:

docker run --rm -it --privileged --pid container:golang --network container:golang nicolaka/netshoot

Observação: a imagem nicolaka/netshoot (github.com/nicolaka/netshoot) é uma imagem com diversas ferramentas de rede instaladas. Para Kubernetes a imagem bretfisher/shpod (github.com/bretfisher/shpod) é ótima com diversas ferramentas para fazer debug do cluster.

Por que o container precisa ser privilegiado? Para conseguirmos acessar os arquivos do outro arquivo, vá em /proc/1/root , e você estará no filesystem da aplicação. Onde 1 é o id do processo do app.

wizardzines.com/comics/proc

Antes de capturar os pacotes, bora dar um tutorial rápido de Wireshark? O wireguark é um aplicativo desktop que faz 2 coisas em uma, primeiro ele captura os pacotes passando na maquina e depois ele tem uma interface muito completa para visualizar o tráfego, vendo detalhes de cada pacote, possibilitando filtros e fazendo visualizações como diagramas de estado e estatísticas para ajudar a entender o que está acontecendo.

No nosso caso, como estamos utilizando containers, não vamos ter a interface gráfica do Wireshark, então podemos fazer de duas formas: capturar os pacotes utilizando o tcpdump (que não tem interface gráfica), salvar um arquivo pcap e visualizar no Wireshark. A outra opção é utilizar uma alternativa “terminal” do Wireshark, o termshark, com ele teremos uma experiência parecida com a original.

Para abrir o termshark precisamos especificar uma interface da qual os pacotes serão capturados, no nosso caso só temos uma interface, então não precisamos. Uma vez aberto, podemos ver que mesmo sem mandar muitos requests pro nosso app tem muitos pacotes que não são do nosso interesse, como os pacotes do protocolo ARP. Então é uma mão na roda usar filtros, podemos filtrar por IP, por porta , protocolo, etc …. Tem uma colinha dos filtros nesse link: https://medium.comhacker-toolbelt/wireshark-filters-cheat-sheet-eacdc438969c

Com o termshark aberto e filtrando apenas pacotes HTTP, no print abaixo podemos ver a aplicação rodando no terminal superior esquerdo, um request sendo feito com curl no terminal da direita e abaixo estamos rodando a versão

Fechando o parêntese do nosso tutorial 101 do wireshark, se tiver interesse em um texto aprofundado escreva pra gente :)

Para facilitar nossa vida, tem uma ferramenta que faz essa abordagem de maneira simplificada, o cdebug (github.com/iximiuz/cdebug), com uma feature adicional: fazer redirecionamento de portas não públicas (semelhante ao kubectl port-forward).

Fazendo o scan de vulnerabilidades nas imagens

Até agora o nosso intuito era diminuir o tamanho das imagens, pois dessa forma teríamos uma superfície de ataque menor, mas não medimos se de fato temos menos vulnerabilidades.

Vamos adotar o grype (github.com/anchore/grype), outra opção muito boa é o trivy (github.com/aquasecurity/trivy)

A nossa primeira versão (v1) tem 1334 CVEs :/ , das quais 6 são critical, 257 high, 894 medium, etc.

Já a nossa versão multistage (v2) tem 10x menos vulnerabilidades: com 136 CVEs , das quais 4 critical, 6 high, 36 medium.

Como pode um simples hello world ter 1300 CVEs? Em resumo, é porque imagens baseadas em Debian não atualizam por completo as versões para corrigir as CVEs, vamos falar em mais detalhes na próxima seção.

Debian: Estamos sendo justos com ele?

Vimos que a nossa imagem tem mais de mil vulnerabilidades, mas por que isso acontece? Estou de fato em risco?

A resposta é que provavelmente o problema não é tão grave quanto parece, só que a maneira que os scanners funcionam não bate bem da maneira que o Debian opera. O Debian quando tem sua versão stable declarada todos os pacotes são congelados na versão que estão e são feitos diversos testes para que tudo funcione até que seja lançada ao público a release.

Quando bugs são encontrados, de segurança ou não, o Debian muitas vezes simplesmente aplica a mudança (patch) que corrige o problema em cima da versão que saiu no stable.

Ao passo que os scanners de segurança funcionam identificando os pacotes e outros componentes de software (SBOM) e cruzar com um banco de dados de vulnerabilidades.

Ou seja, os scanners não estão nem aí pras mudanças que o Debian aplicou.

Por exemplo, nossa primeira versão de ambos o trivy e grype reportaram a CVE-2023-23914 (HSTS ignored on multiple requests) no curl, que de fato é uma vulnerabilidade crítica. Pois bora tentar reproduzir a vulnerabilidade?

Na página da CVE (curl.se/docs/CVE-2023-23914.html), basta rodar o seguinte: curl --hsts "" https://curl.se http://curl.se, quando vulnerável, o curl vai fazer o segundo request sem https, mesmo com o site esforçando HSTS. Porém, o comando falha pois a feature de HSTS nem foi introduzida na versão do curl adotada no Debian Bullseye. Ou seja, é um falso positivo.

Um excelente blog post falando sobre essa situação é Image Vulnerability Scanning and You -- linuxserver, da linuxserver, grupo que disponibiliza imagens docker para diversas aplicações open source, no blog post eles mostram como esses resultados aparentemente alarmante de scanners de vulnerabilidades, são falsos positivos. Eles deram um exemplo de uma vulnerabilidade, a CVE-2020-16156, que só pode ser explorada caso um usuário altere configurações de maneira maliciosa, ou seja, para explorar a vulnerabilidade você já teria que estar comprometido, o que é um problema muito maior.

O scanner grype tem uma opção para apenas considerar vulnerabilidades que de fato serão corrigidas (–only-fixed), rodando essa opção na nossa v2, as 130 vulnerabilidades caem para 2, uma de severidade medium e outra unknown.

Imagens chainguard

As imagens da Chainguard são imagens produzidas pela empresa de mesmo nome que, além de serem menores, fazem um grande esforço para as imagens estarem com os pacotes atualizados e com as correções de segurança aplicadas.

Outra feature legal dessas imagens é que toda vez que um pacote é instalado o SBOM dele é automaticamente gerado, criando um melhor lastro do conteúdo da imagem.

Para quem está acostumado com imagens baseadas em debian precisa se acostumar pois as imagens do chainguard são baseadas no alpine, ou seja, ao invés do gerenciador de pacotes apt é utilizado o apk, então tem uma certa “curva de aprendizado” para se acostumar, uma dica pra encontrar os pacotes equivalentes é utilizar o apk search com cmd para procurar o pacote que contém aquele comando, por exemplo para instalar o ldd, faça: apk search cmd:ldd e o pacote associado será o posix-libc-utils.

Outra diferença entre as imagens baseadas no Debian e do Alpine é o shell, nas imagens Debian o shell adotado é o bash, enquanto no Alpine é um shell mais limitado o ash (provido pelo busybox), então se seus scripts contém “bashismos” você precisa ver o que faz mais sentido entre tornar eles interoperáveis (posix-compliant) ou instalar o bash na imagem.

Apesar de ser baseada no alpine, as imagens chainguard não utilizam a biblioteca padrão musl do alpine, mas sim a implementação mais difundida da GNU a glibc, vamos retomar essa diferença mais a frente.

Bora colocar nossa app Python para usar o Chainguard?

FROM cgr.dev/chainguard/wolfi-base

ARG pyversion=3.12

RUN apk add python-${pyversion} py${pyversion}-pip python-${pyversion}-dev \
    build-base openssl-dev vim curl && \
    rm -rf /var/cache/apk/*

USER nonroot
WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot . /home/nonroot/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-cache-dir -r requirements.txt

ENV PATH="/home/nonroot/app/.venv/bin:$PATH"

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v3

A imagem base da Chainguard é o wolfi, ela é uma imagem pequena da qual instalamos os pacotes de que precisamos.

A principal diferença é que os pacotes têm outros nomes, por exemplo, o equivalente do build-essential é o build-base, e diferentemente do Debian podemos escolher qual versão do Python vamos adotar.

Já vem com um usuário não root, então basta utilizar ele.

Quem tiver curiosidade em inspecionar a imagem com o dive, os SBOMs SPDX de cada pacote estão em /var/lib/db/sbom/.

E as CVEs? É aqui que a Chainguard brilha, nenhuma CVE reportada no Trivy ^_^, porém apesar da Chainguard ter uma postura bastante proativa para manter toda cadeia de suprimento segura e atualizada, você precisa periodicamente rebuildar as imagens para usar as versões mais atuais dos pacotes e das nossas bibliotecas de que dependemos (que permitimos que sejam atualizadas para versões compatíveis).

Quem tiver interesse em aprender mais sobre as imagens chainguard eles tem excelentes guias com passo-a-passo, exemplo e cursos em edu.chainguard.dev gostei bastante da dinâmica dos cursos, com vídeos curtos e acompanhados de um texto do que é mostrado no vídeo.

Criando imagens distroless da Chainguard com Melange

No exemplo anterior utilizamos a imagem base da Chainguard para o nosso app Python, porém ela não é uma imagem distroless, visto que ela tem um shell, o apk e etc. … A Chainguard tem imagens distroless do Python e outras linguagens e projetos, porém só podemos usar gratuitamente sua tag latest

Para termos uma imagem distroless pra chamar de nossa, vamos utilizar o sistema de build da Chainguard, o Melange.

edu.chainguard.dev/open-source/build-tools/melange/overview

Primeiramente precisamos empacotar nossa app python em um pacote alpine apk usando o melange, para fazer esse empacotamento teremos uma pipeline de build no melange declarada a partir do arquivo yaml abaixo:

package:
  name: hello-crud
  version: 0.0.1
  epoch: 0
  description: REST hello world
  copyright:
    - license: Apache-2.0
      paths:
        - "*"
  dependencies:
    runtime:
      - python-3.12

environment:
  accounts:
    groups:
      - groupname: nonroot
        gid: 65532
    users:
      - username: nonroot
        uid: 65532
    run-as: nonroot
  contents:
    keyring:
      - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
      - ./melange.rsa.pub
    repositories:
      - https://packages.wolfi.dev/os
    packages:
      - busybox
      - glibc
      - glibc-locale-posix
      - openssl-dev
      - build-base
      - python-3.12
      - py3.12-pip

pipeline:
  - name: Build Python application
    runs: |
      VENVDIR=/usr/share/webapps/hello-server/venv
      EXECDIR="${{targets.destdir}}/usr/bin"
      WEBAPPDIR="${{targets.destdir}}/usr/share/webapps/hello-server"
      mkdir -p "${EXECDIR}" "${WEBAPPDIR}" /usr/share/webapps/hello-server
      cd /usr/share/webapps/hello-server
      echo -e "\n\n#########################################\n"
      python3 -m venv ${VENVDIR}
      cd /home/build
      sh -c ". ${VENVDIR}/bin/activate && pip3 install --no-compile --no-cache-dir -r requirements.txt && pip3 uninstall -y pip"
      cp -r ${VENVDIR} ${WEBAPPDIR}
      cp app.py ${WEBAPPDIR}
      chown -R 65532:65532 ${WEBAPPDIR}

melange.yaml

Nesse yaml a gente declara as informações do nosso pacote, como nome, versão e licença e as dependências em tempo de execução dele, no nosso caso apenas o python3.12.

Em seguida declaramos o que o nosso ambiente de build precisa: os pacotes de build, o usuário não root e os repositórios wolfi para usarmos os pacotes da chainguard (poderíamos usar o alpine se quiser).

Por fim a pipeline de build em si, ou seja uma sequência de comandos shell que builda a app e copia tudo para uma pasta em targets.destdir.

Fizemos uma pequena alteração no nosso pip install, utilizando a flag –no-compile que não gera os arquivos .pyc, dessa forma o venv fica menor. Tem um excelente blog post explicando os trade-offs dessa abordagem: Stop putting this into your Python Dockerfiles -- Aleksa Cukovic

Bora buildar nosso pacote?

Na primeira vez precisamos gerar uma chave privada para assinar o pacote:

docker run --rm -v "${PWD}":/work cgr.dev/chainguard/melange keygen

Não se preocupe com os comandos, criei um makefile no repositório que executa os comandos em sequência.

Então o build:

docker run --privileged --rm -v "${PWD}":/work cgr.dev/chainguard/melange build melange.yaml --arch amd64 --signing-key melange.rsa

Pronto! Uma vez executado, teremos nosso pacote alpine na pasta packages.

Com o nosso pacote alpine pronto, bora criar o container que faz o deploy do nosso app? É agora que surge o apko, nele declaramos o container usado em tempo de execução (runtime) contendo o pacote previamente gerado, é como se fosse um Dockerfile, mas feito de forma declarativa.

Agora o nosso apko.yaml:

contents:
  keyring:
    - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
    - ./melange.rsa.pub
  repositories:
    - https://packages.wolfi.dev/os
    - '@local /work/packages'
  packages:
    - hello-crud@local
accounts:
  groups:
    - groupname: nonroot
      gid: 65532
  users:
    - username: nonroot
      uid: 65532
  run-as: nonroot
environment:
  PATH: /usr/share/webapps/hello-server/venv/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin
work-dir: /usr/share/webapps/hello-server/
entrypoint:
  command: gunicorn -w 2 -b 0.0.0.0:8000 --access-logfile - --error-logfile - app:app

apko.yaml

No nosso apko declaramos os repositórios da chainguard (ou alpine), os pacotes: no nosso caso apenas o pacote da nossa app, o usuário não root e as condições pro nosso app rodar como variaveis de ambiente e o comando entrypoint.

Para buildar nossa imagem:

docker run --rm --workdir /work -v ${PWD}:/work cgr.dev/chainguard/apko build apko.yaml hello-crud:test hello-crud-server.tar --arch host

Cuidado que a imagem não é carregada automaticamente no docker, você precisa fazer docker image load -i hello-crud-server.tar

E o resultado? A imagem ficou com 65MB \o/

Em retrospectiva a nossa primeira versão do dockerfile tinha 570MB, a versão multistage usando debian 190MB e agora quase 10x menor com 65MB, não vai embora ainda não porque vamos melhorar ainda mais.

Distroless sem o melange e apko

Na seção anterior mostrei como usar o melange e o apko para declarativamente criar imagens mínimas para sua aplicação, porém é um sistema de build dedicado que você vai ter que aprender e manter, minha intenção era mostrar que não é um bicho de sete cabeças , pelo contrário o melange e o apko são bastante amigáveis.

Porém pra quem não quiser aprender um novo sistema de build e não se importa em quebrar a cabeça fazendo um Dockerfile especializado temos essa alternativa.

A peça crítica para esse Dockerfile funcionar é que o gerenciador de pacotes apk suporta chroot, ou seja podemos instalar pacotes em outro sistema de arquivos por “fora da caixa”, sem precisarmos instalar o apk em si ou ter um shell para conseguir rodar qualquer comando durante o build.

talk is cheap, show me the code:

ARG ROOTFS=/new_root
ARG pyversion=3.12
# nonroot user
ARG PGID=1000
ARG PUID=1000

FROM cgr.dev/chainguard/wolfi-base AS appbuilder

ARG pyversion

RUN apk add python-${pyversion} py${pyversion}-pip python-${pyversion}-dev build-base openssl-dev && \
    rm -rf /var/cache/apk/*

USER nonroot
WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot . /home/nonroot/app

RUN python3 -m venv .venv && . .venv/bin/activate && \
    pip3 install --no-compile --no-cache-dir -r requirements.txt && \
    pip3 uninstall -y pip

FROM cgr.dev/chainguard/wolfi-base AS chrootbuilder

ARG ROOTFS
ARG pyversion
ARG PGID
ARG PUID

RUN mkdir -p $ROOTFS/etc/apk/keys && \
    cp -v /etc/apk/keys/* $ROOTFS/etc/apk/keys/ && \
    cp -v /etc/apk/repositories  $ROOTFS/etc/apk/repositories

RUN apk add shadow && \
    rm -rf /var/cache/apk/*

RUN apk add --no-commit-hooks --root $ROOTFS --initdb glibc glibc-locale-posix \
    python-${pyversion} &&\
    rm -rf $ROOTFS/var/cache/apk/*

RUN groupadd -g ${PGID} -R $ROOTFS nonroot &&\
    useradd -u ${PUID} -g nonroot -m --shell /bin/sh -R $ROOTFS nonroot

FROM scratch AS runtime

ARG ROOTFS

COPY --from=chrootbuilder $ROOTFS /

USER nonroot
WORKDIR /home/nonroot/app

COPY --chown=nonroot:nonroot --from=appbuilder /home/nonroot/app/ /home/nonroot/app/

ENV PATH="/home/nonroot/app/.venv/bin:$PATH"

EXPOSE 8000

CMD [ "gunicorn", "-w", "2", "-b", "0.0.0.0:8000", "--access-logfile", "-" , "--error-logfile", "-", "app:app" ]

Dockerfile-v4

O Dockerfile tem 3 estágios: um que faz o “build” do nosso venv e da app, um que gera o ambiente chroot com as dependências de tempo de execução e o estágio final que junta os dois. Fiz dessa forma para separar a nossa “imagem base” com o runtime de python, que é desacoplado da nossa app e o build do venv que aí sim depende da nossa app, dessa forma rebuilds com cache só fazem o build o que mudou.

O grande pulo do gato é o uso das flags do apk: -R apontando para chroot, –no-commit-hooks pois os hooks não se aplicam quando usando chroots e –initdb para inicializar o database do apk, sem isso o database não será gerado e ferramentas de SBOM não funcionam.

E o resultado? O tamanho ficou muito próximo do apko (65MB), com apenas alguns KBs de diferença.

glibc vs musl: O inimigo agora é outro

Quanto comecei minha jornada com Docker e comecei a colocar meus apps Python no docker, na época pelo menos era inviável usar imagens base alpine pois não tinha os wheels pré-compilados para biblioteca padrão c musl do alpine então qualquer app que precisava do numpy o build demorava demais pra compilar, então deixei de lado as imagens alpine.

Mas agora quando tentei novamente o pypi tem os wheels pré-compilados pro musl e outras arquiteturas como o arm \o/

Porém as imagens da chainguard apesar de serem baseadas no alpine não utilizam a musl, mas sim a implementação mais difundida a glibc, tem um artigo deles bastante completo explicando o diversos aspectos por trás dessa decisão, como compatibilidade com binários dinamicamente linkados:

glibc vs. musl -- Chainguard

O dockerfile ficou igual ao dockerfile-v4, porém mudando a imagem base do wolfi para a release mais recente do alpine (alpine:3.23). E o tamanho da imagem ficou uns ~15MB menor que a do melange (50MB).

Bora fazer uma retrospectiva de como foi evoluindo o tamanho da nossa imagem Python? Podemos ver na tabela abaixo que começamos com o nosso Dockerfile v0 bem tradicional com quase 600MB e com o multistage o tamanho caiu para um quarto da v0 e metade disso usando distroless.

Versão	Tamanho [MB]	Percentual de v0
v0	570	-
v1 (delete dos caches e índices)	520	91%
v2 (multistage)	130	22%
v4 (distroless chroot/melange)	65	11%
v5 (distroless com alpine+musl)	50	9%

Observação: Omitimos a v3 pois nela o objetivo era migrar para imagens baseadas em alpine, sem o foco em otimizar seu tamanho.

Hadolint

Pra fechar o texto, a última dica é utilizar o Hadolint (github.com/hadolint/hadolint), ele dá excelentes dicas para as boas práticas de que falamos aqui, tem extensão pro VSCode e de quebra roda o outro linter excelente para shell shellcheck.net dentro das instruções RUN, então você leva dois linters dentro de um.

Conclusão

Resgatando a provocação inicial, espero a essa altura ter te convencido de que dockerfile não é tudo igual, que não posta a aplicação funcionar para termos um bom dockerfile.

O princípio que mais exploramos é tornar a imagem enxuta possível, pois além de imagens menores serem mais performáticas, elas têm uma superfície de ataque menor e dessa forma conseguimos identificar quais dependências são realmente necessárias em tempo de execução da aplicação.

Para “enxugar” as imagens vimos como o dive é uma ferramenta muito prática para dissecar camada a camada as imagens e identificar os pontos de melhoria, e o conceito de multi-stage para separar o build e o runtime.

Por fim, levando ao extremo o objetivo do multi-stage , vimos o conceito das imagens distroless e como fazer elas com o melange e o apko, porém o desafio de debugar essas imagens.

Espero que esse texto te auxilie a criar imagens Docker melhores e muito obrigado por chegar até aqui!

ansible localhost -a "/bin/echo Primeiros passos com o Ansible"

Tue, 12 Jul 2022 10:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 12Jul2022

Lembra quando precisou configurar pela primeira vez seu computador? Possivelmente precisou instalar o git, docker, VSCode, um navegador decente, um shell bacana como o zsh, mó trampo né?

Hoje vamos falar de uma ferramenta de automação de configuração, o Ansible, que permite que a configuração e manutenção dos ambientes seja feita de forma automatizada, poupando bastante tempo.

logo do Ansible

O que é o Ansible? O Ansible é uma ferramenta de automação de configuração e manutenção de ambientes, e atua agilizando e escalando essas atividades.

As principais vantagens do Ansible são sua facilidade de aprendizado, e não ter a necessidade de instalar um agente da ferramenta nas máquinas gerenciadas. A desvantagem acaba sendo que como não existe um agente executando o Ansible este processo não escala bem, ou seja para gerenciar muitos computadores o nó de controle do Ansible precisa ser potente.

Instalando o Ansible

Para instalar o Ansible é necessária a instalação da linguagem python e então basta instalar o executável através do pip install

pip install ansible

Uma funcionalidade que gosto muito no python são os ambientes virtuais (venv), eles são nativos da linguagem e permitem que você possa ter um “ambiente python” diferente para cada projeto, e assim instalar as dependências adequadas de cada projeto sem interferir nos demais.

Normalmente o venv fica dentro da pasta do projeto, e é ignorado no .gitignore. Para criar o venv faça

python3 -m venv venv

Agora toda vez que for utilizar o venv ative com:

source venv/bin/activate

Obs: se estiver usando zsh ou outro shell coloque a extensão do seu shell (no zsh ficaria activate.zsh).

Repare que o prompt (PS1) ficou diferente, contendo o nome do venv (venv).

Para evitar problemas, a primeira vez que crio o venv atualizo o pip e outras ferramentas:

pip install -U pip setuptools wheel

Com venv criado basta só instalar o ansible normalmente (pip install ansible).

Bora testar a instalação? Rode o seguinte

ansible -m ping localhost

Se tiver a seguinte saída significa que deu bom:

[WARNING]: No inventory was parsed, only implicit localhost is available

localhost | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

Bora para o hello world?

ansible localhost -a "/bin/echo ola mundo"

[WARNING]: No inventory was parsed, only implicit localhost is available

localhost | CHANGED | rc=0 >>

ola mundo

Como o Ansible funciona?

O Ansible é executado no nó de controle e conecta via o protocolo ssh nos nós gerenciados. Para executar a ferramenta recebe como entrada um arquivo de texto que é o inventário com informações dos nós gerenciados, como os IPs e credenciais. A outra entrada é o playbook, um arquivo no formato yaml, que contém as instruções a serem executadas.

Um requisito para o ansible é que os nós gerenciados precisam do python instalado, porém é possível rodar o ansible de forma limitada para instalar o python para contornar isso ;)

Fonte: twitter.com/scienceshitpost

Montando o inventário

Antes de montar o inventário precisamos de pelo menos uma máquina para conectarmos via ssh, no meu caso utilizei uma raspberrypi e uma máquina virtual. Sem enrolação, vamos ao inventário:

inventario.ini:

[pies]
rpi4 ansible_host=192.168.1.205 ansible_user=piuser ansible_password=pipass ansible_become=yes

[vms]
rockylinux ansible_host=192.168.121.182 ansible_user=rockyuser ansible_password=rockypass

[vms:vars]
ansible_become=yes

[all:vars]
ansible_port=22
ansible_become_method=sudo
ansible_python_interpreter=python3
ansible_become_password="{{ ansible_password }}"

O inventário pode ser escrito no formato ini ou no formato yaml, aqui optei pelo ini.

Nesse exemplo foram definidas duas máquinas a rpi4 pertencente ao grupo pies e rockylinux pertencente ao grupo vms.

E essas variáveis?

ansible_host é o ip ou domínio da máquina.
ansible_port é porta usada pelo ssh, por padrão é a 22, ou seja nem precisaríamos mudar no nosso caso.
ansible_user e ansible_password usuário e senha do ssh utilizados para conectar.
ansible_become indica se deve elevar privilégios ou não, ou seja rodar como usuário root.
ansible_become_method indica o método utilizado para elevar privilégios, aqui estamos utilizando o sudo, mas poderia ser su e utilizar a senha do root.

O inventário pode ser montado de diversas formas e tem várias outras variáveis, consulte a documentação para saber mais: How to build your inventory. Uma coisa que gosto de fazer é utilizar a opção ansible_ssh_common_args com -F ssh_config, onde ssh_config (man page) é um arquivo de configuração do ssh.

As vezes não conseguimos acessar diretamente todas as máquinas, pois é exposto apenas uma máquina, chamada de bastião que atua como proxy para acessar as outras máquinas dentro da rede privada. No ssh_config podemos usar a opção ProxyJump.

Outra vantagem é que fica mais fácil de acessar manualmente uma máquina, basta fazer ssh -F ssh_config nome_maquina e pronto ;)

Bora testar o inventário? Rode

ansible -m ping -i inventario.ini all

Putz, deu ruim, to use the ‘ssh’ connection type with passwords or pkcs11_provider, you must install the sshpass program . Por padrão o ansible conecta autenticando com chaves ssh, não a senha, então precisamos instalar o sshpass. Bastou um sudo apt install sshpass , pra quem tem mac tem um pacote no brew (brew install hudochenkov/sshpass/sshpass).

Agora foi:

rockylinux | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

rpi4 | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

Rodando comandos adhoc

Até aqui só fizemos -m ping, mas podemos fazer praticamente qualquer coisa, no ansible as tarefas são executadas através de módulos e vamos mostrar alguns deles aqui.

Caso não seja especificado nenhum módulo o ansible executa por padrão o módulo command, vou executar o comando hostnamectl, que exibe diversas informações do computador:

ansible -i inventario.ini -a hostnamectl all

rockylinux | CHANGED | rc=0 >>

   Static hostname: localhost.localdomain

         Icon name: computer-vm

           Chassis: vm

        Machine ID: 3d137ab51d6c4a1098281d0f08170bce

           Boot ID: 95f4fb49069040b484410562dbbf344c

    Virtualization: kvm

  Operating System: Rocky Linux 8.6 (Green Obsidian)

       CPE OS Name: cpe:/o:rocky:rocky:8:GA

            Kernel: Linux 4.18.0-372.9.1.el8.x86_64

      Architecture: x86-64

rpi4 | CHANGED | rc=0 >>

   Static hostname: rpi4

         Icon name: computer

        Machine ID: 8e5eb04e49a74e26952554ad422b19fb

           Boot ID: 18563abe0fa6420fb55488b28401304e

  Operating System: Debian GNU/Linux 11 (bullseye)

            Kernel: Linux 5.10.0-15-arm64

      Architecture: arm64

Deu bom! Conseguimos visualizar as infos sobre as máquinas. Por curiosidade, qual é desse rockylinux? A redhat descontinuou o centos em dez/2020, que é uma versão gratuita e comunitária do redhat enterprise linux (RHEL) e com o fim do centos dois projetos surgiram como sucessores compatíveis ao centos, o rockylinux e o almalinux.

Bora instalar um pacote como o neofetch? Só mandar um sudo apt install neofetch, certo? No nosso caso uma máquina tem uma distro baseada em redhat ou seja não utiliza o gerenciador de pacotes apt, mas o dnf. Por isso vamos utilizar o módulo package que é genérico e funciona com diversos gerenciadores de pacotes.

xkcd #1654

Vendo a documentação do módulo package, temos 3 argumentos, dos quais apenas 2 são obrigatórios, o nome dos pacotes (name) e o estado (state) como instalado (present) ou removido (absent).

ansible -i inventario.ini -m package -a "name=neofetch state=present" all

rpi4 | CHANGED => {

    "cache_update_time": 1655557364,

    "cache_updated": false,

    "changed": true,

    "stderr": "",

    "stderr_lines": [],

    "stdout": "Reading package lists...\nBuilding dependency tree… [...]

Rodando o neofetch: ansible -i inventario.ini -a neofetch all

Uma opção que facilita muito é a --limit que como o nome sugere limita a execução a algumas máquinas, pode ser especificada múltiplas vezes. Até então utilizamos o all que executa em todas as máquinas. Você pode trocar o all por um grupo(s) ou máquina(s) . E também podemos limitar qual não queremos que sejam incluídas, utilizando o ! como operador de negação.

Por exemplo, queremos reiniciar todas as máquinas, excepto as que pertencem ao grupo vms:

ansible -i inventario.ini -m reboot all --limit !vms

rpi4 | CHANGED => {

    "changed": true,

    "elapsed": 68,

    "rebooted": true

}

Usando o ansible-vault para proteger segredos

Quando criamos o inventário, colocamos as credenciais de acesso, isso não é uma boa prática pois pode acabar expondo essas credenciais. O que podemos fazer nesses casos?

Uma opção simples é tirar as senhas do inventário e digitar apenas quando precisar, utilizando as opções –ask-pass (ou abreviando -k) e –ask-become-pass (abreviando -K).

Mas vamos focar na abordagem do ansible-vault, que funciona como um gerenciador de senhas, onde os segredos ficam armazenados em um arquivo que está protegido por uma única senha.

Para usar o ansible-vault vamos primeiro tirar as senhas do inventário:

inventario.ini:

[pies]
rpi4 ansible_host=192.168.1.205 ansible_user=piuser  ansible_password="{{ rpi4_pass }}"

[vms]
rockylinux ansible_host=192.168.121.182 ansible_user=rockyuser ansible_password="{{ rocky_vm_pass }}"

[all:vars]
ansible_become=yes
ansible_become_method=sudo
ansible_python_interpreter=python3
ansible_become_password="{{ ansible_password }}"

Repare que em ambas as máquinas a variável a ansible_password estão sendo recebidas como referência.

Crie um arquivo que vamos chamar de vault.yml

vault.yml

---
rpi4_pass: 'pipass'
rocky_vm_pass: 'rockypass'

Agora que a mágica acontece, vamos criptografar o arquivo: ansible-vault encrypt vault.yml e digite a senha desejada. Por curiosidade, bora ver o conteúdo do arquivo?

$ANSIBLE_VAULT;1.1;AES256
33303863323038363938333365326637343733313432626231623735666433303965333266383934
6332633534626465353436666539646466633633393362370a353161653663633263663635643466
[...]

Quando precisar editar o vault, basta fazer ansible-vault edit vault.yml

E para carregar os segredos definidos no vault vamos usar a opção –extra-vars (abreviada por -e) onde podemos fazer -e “var=value” mas vamos apontar para um arquivo então -e @vault.yml. E a opção –ask-vault-pass para entrar com a senha do vault

ansible -i inventario.ini -m ping all -e @vault.yml --ask-vault-pass

rockylinux | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

rpi4 | SUCCESS => {

    "changed": false,

    "ping": "pong"

}

Preciso digitar a senha do vault toda vez? Não necessariamente, uma abordagem é colocar a senha em um arquivo local e utilizar a opção –vault-password-file , mas sou preguiçoso :P e vou deixar configurado em um arquivo de configuração, o ansible.cfg edai fica tudo setado lá 😊

ansible.cfg

[defaults]
host_key_checking = True
inventory = inventario.ini
vault_password_file = ../.arquivo_com_a_senha.txt

Documentação com todas opções do ansible.cfg: Ansible Configuration Settings

Outra abordagem é a conhecida pela buzzword GitOps, que consiste em rodar o ansible no próprio repositório onde ficam os playbooks do ansible, utilizando um sistema de integração contínua, como github actions que falamos anteriormente aqui. Dessa forma a senha do vault pode ser passada via variável de ambiente e colocada em temporariamente um arquivo ou via argumento do comando.

Escrevendo nosso primeiro playbook

Chegou a hora! Bora escrever nosso primeiro playbook. Para isso vamos subir um servidor web, o apache, para hospedar um site um site estático.

Quando fui instalar o apache no rockylinux deu ruim, porque o pacote no debian é o apache2 mas no rockylinux é httpd. Como faz agora? Como eu faço pro ansible detectar que a máquina é o rockylinux ou debian e tratar adequadamente cada caso?

A ferramenta roda automaticamente um módulo chamado setup que obtém diversas infos das máquinas, e disponibiliza em uma variável chamada ansible_facts.

Fazendo ansible -m setup -e @vault.yml all obtive:

rpi4 | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "192.168.1.205"
        ],
        [...]
        "ansible_distribution": "Debian",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_file_path": "/etc/os-release",
        "ansible_distribution_file_variety": "Debian",
        "ansible_distribution_major_version": "11",
        "ansible_distribution_release": "bullseye",
        "ansible_distribution_version": "11",
        "ansible_os_family": "Debian",
        [...]
}

rockylinux | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "192.168.121.182"
        ],
        [...]
        "ansible_distribution": "Rocky",
        "ansible_distribution_file_parsed": true,
        "ansible_distribution_file_path": "/etc/redhat-release",
        "ansible_distribution_file_variety": "RedHat",
        "ansible_distribution_major_version": "8",
        "ansible_distribution_release": "Green Obsidian",
        "ansible_distribution_version": "8.6",
        "ansible_os_family": "RedHat",
        [...]
}

Com isso, podemos usar a variável ansible_distribution (Debian e Rocky) ou ansible_os_family (Debian e RedHat), optei pela ansible_os_family para que nosso playbook seja mais genérico.

playbook.yml

---
- name: Configura um site estatico.
  hosts: all
  become: true

  vars:
    apache_name_dict:
      "Debian": apache2
      "RedHat": httpd

  handlers:
    - name: restart apache
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: restarted

  tasks:
    - name: Instala o apache.
      package:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: present

    - name: Copia o html da pag.
      copy:
        src: page.html
        remote_src: no
        dest: "/var/www/html/index.html"
        mode: 0664
      notify: restart apache

    - name: Habilita o servico do apache.
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: started
        enabled: true

O playbook funciona da seguinte forma:

Primeiro é instalado o pacote do apache, usando uma variável para mapear o nome correto do pacote.
Copia o html do nosso site, o html precisa estar localizado ao lado do playbook, mas caso o arquivo já estivesse no nó gerenciado basta trocar a opção remote_src para yes.
Habita o serviço do apache para que o mesmo seja iniciado automaticamente quando a máquina é iniciada.

O que é esse notify na task de copiar o html? Pense no seguinte: depois de copiar o html preciso que o apache seja reiniciado para carregar o html da página que acabamos de enviar, mas e se o html que estiver lá não foi alterado? Dessa forma o Ansible só reinicia o apache caso necessário, chamando o handler previamente definido.

Bora escrever sem usar o handler, pra ficar mais claro?

playbook2.yml

---
- name: Configura um site estatico.
  hosts: all
  become: true

  vars:
    apache_name_dict:
      "Debian": apache2
      "RedHat": httpd

  tasks:
    - name: Instala o apache.
      package:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: present

    - name: Copia o html da pag.
      copy:
        src: page.html
        remote_src: no
        dest: "/var/www/html/index.html"
        mode: 0664
      register: html_copy

    - name: restart apache.
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: restarted
      when: html_copy.changed

    - name: Habilita o servico do apache.
      service:
        name: "{{ apache_name_dict[ansible_os_family] }}"
        state: started
        enabled: true

Nessa versão do playbook, repare que na task de copiar o html estamos fazendo register: html_copy como o nome sugere estamos registrando o resultado daquela task em uma variável. E na task de reiniciar o apache é acionada apenas quando mudou, em when: html_copy.changed.

Para rodar o comando é sugestivo: ansible-playbook -e @vault.yml playbook.yml

Será que o site tá de pé? Abrindo o navegador no ip da VM:

Uma coisa que você precisa ficar de olho quando escreve seus playbooks é se eles são idempotentes, que significa que o efeito de rodar o playbook é o mesmo independente de quantas vezes o mesmo foi executado. Para quem curte linguagens funcionais tá ligado qualé: O playbook não pode ter efeitos colaterais.

Na prática, assim que rodar a primeira vez execute novamente e veja no final se teve alguma task como changed.

O principal desafio para tornar os playbooks idempotentes acontece quando as tasks são do tipo command ou shell, afinal como o ansible vai saber se a task foi executada anteriormente com sucesso?

Nesses casos, uma possibilidade é utilizar o parâmetro chamado creates, disponível nos módulos de command e shell, que aponta para um arquivo marcador que seu shell script ou command precisa criar quando executado com sucesso.

Bora ver na prática?

playbook3.yml

---
- hosts: all
  become: true

  tasks:
    - name: inicializa um arquivo
      shell: echo "passei por aqui" > /etc/marcador_xpto.txt
      args:
        creates: /etc/marcador_xpto.txt

Repare que quando executamos a primeira vez no recap a task foi changed, mas na segunda vez não houve mudanças.

Quem tiver interesse, tem um texto excelente que até saiu no hacker news com várias dicas de como escrever scripts bash idempotentes: How to write idempotent Bash scripts – Fatih Arslan

Conclusão

Uma regra de ouro é: Antes de sair automatizando, primeiro documente o processo manual, quais recursos sua aplicação precisa? Com os recursos disponíveis, como deve ser feita a configuração da aplicação? Dessa forma fica fácil de vislumbrar o todo e não precisa sair caçando nos códigos. Apesar do manifesto ágil dar preferência a ter um software funcional a documentação abrangente, sugiro não deixar de documentar no início essas definições.

Para aprender ansible, a melhor referência é o livro do Jeff Geerling, Ansible for DevOps o livro tem vários exemplos e dicas. Pra quem prefere o formato de vídeos, no início da pandemia o autor trouxe o conteúdo do livro em forma de lives: Ansible 101 playlist. E pra quem prefere ir direto nos códigos os exemplos estão disponíveis nesse github: github.com/geerlingguy/ansible-for-devops

Obrigado por acompanhar esse texto, espero que te ajude, caso tenha algum feedback ou dúvida não hesite em entrar em contato.

Como criar um pendrive de instalação com vários sistemas

Sun, 08 May 2022 14:00:00 -0300

Conheça o Ventoy, a ferramenta que nos ajuda a fazer isso

Obs.: Originalmente publicado no computando-arte dia 9Maio2022

Quando vou ajudar alguém a formatar seu computador tenho esse problema, preciso levar vários pen drives preparados dependendo de qual sistema a pessoa quer instalar (como o Windows, o Ubuntu, PopOS, Manjaro e etc …). Isso acontece porque só dá para ter um sistema operacional por pen drive.

Hoje vou falar de uma solução desse problema, criar um pen drive multiboot contendo vários sistemas em um único pen drive, utilizando o Ventoy 🤯

Marvin Meyer, on unsplash

Domando o destruidor de discos (dd)

Antes de mostrar o esquema multiboot, vou mostrar o esquema tradicional de gravar um pendrive usando o tradicional comando dd no Linux.

Pra quem usa Windows calma aí que já mostro outra opção.

A tarefa de gravar um pendrive bootável com o dd consiste de 6 tarefas, são elas:

Baixar a imagem do sistema operacional.
Verificar se a imagem não está corrompida ou adulterada.
Plugando o pendrive e identificando onde “subiu”.
Fazer um umount no pendrive.
De fato, gravando a imagem com o dd.
Removendo o pendrive com segurança.

Antes de tudo precisamos baixar a imagem .iso, que podemos encontrar no site do Ubuntu (releases.ubuntu.com). Usei o link abaixo:

wget https://releases.ubuntu.com/20.04.4/ubuntu-20.04.4-desktop-amd64.iso

É de bom tom sempre verificar se imagem iso não está corrompida ou foi adulterada ;) , com este intuito vamos importar a chave de assinatura do ubuntu:

gpg --keyid-format long --keyserver hkp://keyserver.ubuntu.com --recv-keys 0x46181433FBB75451 0xD94AA3F0EFE21092

Veja que as chaves foram importadas com sucesso:

gpg: key D94AA3F0EFE21092: public key "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>" imported
gpg: key 46181433FBB75451: public key "Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>" imported
gpg: Total number processed: 2
gpg:               imported: 2

Em seguida vamos baixar os hashes da imagem e a assinatura:

wget https://releases.ubuntu.com/20.04.4/SHA256SUMS
wget https://releases.ubuntu.com/20.04.4/SHA256SUMS.gpg

Verificando a assinatura:

gpg --verify SHA256SUMS.gpg SHA256SUMS

Deu bom! Repare no resultado do comando (good signature …)

gpg: Signature made qui 24 fev 2022 17:36:20 -03
gpg:                using RSA key 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Good signature from "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>" [unknown] # <--------
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092

Por fim, verificando a imagem:

sha256sum --ignore-missing -c SHA256SUMS
ubuntu-20.04.4-desktop-amd64.iso: OK

Tá safe! Bora gravar essa imagem. Para isto, antes de plugar o pen drive execute o comando lsblk para listar os dispositivos de armazenamento, então plugue o pendrive e execute o lsblk novamente e veja se “onde o pendrive subiu” (comparando quando rodou o lsblk a primeira vez), isto é, se foi conectado ao sdb, sdc ou sdd etc … Aqui “subiu” como sdb.
Sempre bom fazer umount antes:

sudo umount /dev/sdb*

Finalmente gravando a imagem:

sudo dd if=ubuntu-20.04.4-desktop-amd64.iso of=/dev/sdb bs=1M status=progress ; sync

Aponte para o endereço da imagem no argumento if, e aponte para o endereço do pen drive no argumento of. Preste atenção se de fato está apontando para o pen drive em /dev/sdb, não coloque a partição /dev/sdb1 ou 2, é só sdb!

Observação: O comando sync faz com que a imagem completa seja de fato escrita no pendrive, não somente no cache.

Espere a gravação finalizar (demora alguns minutos) e por fim vamos remover com segurança o pendrive:

sudo udisksctl power-off -b /dev/sdb

Gravando utilizando o etcher

Uma alternativa ao dd é utilizar o etcher, que está disponível no Windows, Mac e Linux, super simples de usar! Basta entrar no site balena.io/etcher/ e baixar o programa, então selecionar a imagem iso, o pen drive e clicar em Flash!, conforme a figura abaixo:

Multiboot com Ventoy

Chegou a hora de falar do Ventoy \o/

Instalar o ventoy é tranquilo, basta ir na pagina de releases no Github do Ventoy github.com/ventoy/Ventoy/releases/, estou utilizando a versão 1.0.73:

wget https://github.com/ventoy/Ventoy/releases/download/v1.0.73/ventoy-1.0.73-linux.tar.gz

Verificando o download:

sha256sum ventoy-1.0.73-linux.tar.gz | grep ba1b61864598af2db662e393043c8759213869419ad95adb71fb5d92484f4b7d

Extraindo o tar:

tar xvf ventoy-1.0.73-linux.tar.gz

Gravando o ventoy:

sudo umount /dev/sdb*
cd ventoy-1.0.73/
sudo ./Ventoy2Disk.sh -i /dev/sdb

Quando finalizar a gravação, basta copiar as isos para uma partição que foi criada e sucesso.

Quando ligar o computador, e apertar F12 (ou a tecla do seu fabricante) com esse pendrive a tela do ventoy vai aparecer, no qual você pode escolher qual das imagens será utilizada.

Captura de tela do Ventoy, Fonte: ventoy.net/en/screenshot.html

Quando precisar de outro sistema basta colocar a iso na partição do ventoy e usar! Muito prático!

Testei e funcionou bootar tanto no modo legacy (MBR) quanto UEFI ^_^

Adorei o Ventoy :) daqui para frente só preciso de um pendrive na minha caixa de ferramentas quando for atender alguém.

Por que e como fazer um blog técnico

Mon, 21 Mar 2022 14:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 21Março2022

Hoje vou falar de um hábito inesperado que passei a praticar durante a quarentena, o de compartilhar o conhecimento através de textos.

Eu não era um bom aluno de português :/ mas hoje percebo a importância de conseguir se comunicar bem, e como faz toda diferença!

Antes da pandemia, participava de algumas comunidades, hackerspaces e eventos (como a Cryptorave e a CasaHacker), e nesses espaços físicos são construídas diversas atividades colaborativamente.

Edai veio a pandemia que mudou essas interações então comecei a criar esses registros dessas trocas.

Mika Baumeister, unsplash

Acompanhe referências da sua área

O primeiro passo para começar a escrever é ler ;) quem escreve bem normalmente lê muito e na comunicação científica isso não é diferente. Veja o que outras pessoas falam, procure e acompanhe blogs e talks dessas pessoas. Preste atenção em alguns pontos: Como elas explicam determinado conceito? Quais analogias/comparações ela usa? E, principalmente, como apresentar isso para quem está começando e quais detalhes são importantes?

Decida se quer ser anônimo ou não

Uma possibilidade é escrever sem se identificar, dessa forma você não “contamina” o debate com quem você é, onde você trabalha, onde você estudou, com que você interage, sua aparência, enfim, de onde você vem.

Um exemplo disso é o Startup da Real, ele criou um perfil para expor os discursos de empreendedorismo. Depois de produzir vários textos aqui no medium ele amarrou esses textos em um livro chamado “Este livro não vai te deixar rico: Descubra a verdade sobre empreendedorismo, startups e a arte de ganhar dinheiro”. O startup da real, ou Alberto Brandão, revelou sua identidade no talk show do Ronald Rios. Confira aqui ele contando a história: STARTUP DA REAL - Ronald Rios Talk Show #12

Apesar dessas vantagens, vou trazer no próximo tópico um bom motivo para não fazer de forma anônima.

Use seu conteúdo para construir rastros digitais positivos

A internet não esquece! Já deu um google no seu nome completo? O que encontrou? Possivelmente seu currículo lattes ou algum trabalho publicado, talvez até seu perfil no LinkedIn. Mas às vezes tem coisas que você não gostaria que aparecesse (pelo menos com tanto destaque), como por exemplo um processo no JusBrasil, no Diário Oficial ou então alguma nota em disciplina da faculdade. E o mais triste disso é que não temos muito como deletar essas pegadas digitais de forma fácil e rápida.

Ao invés de tentar deletar toda sua presença online e ocupar esses espaços online da forma mais anônima possível, que tal criar um conteúdo legal e que quando pesquisarem você isso vai causar uma ótima primeira impressão?

Quando pesquisarem seu nome no Google vão encontrar seu artigo, seu blog pessoal, uma talk que você fez em algum evento, uma participação em podcast ou live. E as coisas que não tem tanto orgulho só irão aparecer nas últimas páginas da pesquisa, que normalmente as pessoas não procuram. Vi essa excelente proposta no texto da Casey Fiesler, ela estuda os espaços online há anos, e propôs essa abordagem no contexto da hashtag #10YearChallenge, quando acabaram trazendo à tona coisas que a pessoa postou e que hoje em dia não se orgulham. Veja o texto dela: If you’re worried about your digital footprint, don’t destroy it — make it bigger. | by Casey Fiesler

Outros porquês para divulgar conhecimento

Além de ter uma presença online mais positiva, quais outras vantagens de divulgar conhecimento?

Uma habilidade que você acaba desenvolvendo é de colocar em uma ordem linear como abordar determinado assunto. No fundo, você vai escrever uma história com começo, meio e fim. E quando você registra isso logo depois que começou a aprender um assunto novo, vai te ajudar bastante no seu processo de aprendizado.

Quando criar uma documentação quando você tiver que configurar seu ambiente, se você documentar vai ficar mais fácil de reproduzir quando precisar novamente. Como você já escreveu essa documentação, terá pouco trabalho para publicar e vai ajudar quem estiver precisando. Por exemplo, quer aprender como montei meu setup de backups automatizados? Confira aqui: Como parei de me preocupar e passei a adorar minha solução de backups.

Ninguém se importa com seu conteúdo

E isso é bom! Esse post do Gabs Ferreira, do grupo Alura: Ninguém se importa com o seu conteúdo: e isso é bom - Gabs Ferreira trouxe essa perspectiva, só vai!

Se estiver com receio de começar a escrever, pois vão te criticar ou te julgar de alguma forma, não se preocupe! A maioria das pessoas nem vai consumir seu conteúdo. Então escreva pensando em você, como isso vai te ajudar a aprender melhor, a se expressar melhor, a colocar as coisas em uma ordem linear e etc … E se conseguir impactar positivamente mesmo que for apenas uma pessoa isso já valeu a pena.

Pra quem curte estatísticas, na pegada do princípio de pareto (80% dos efeitos vêm de 20% das causas) temos a regra 90-9-1 (ou regra do 1%) que mostra que via de regra para qualquer comunidade na internet 90% dos internautas vão apenas consumir de forma passiva, sem interagir de nenhuma forma (os “Lurkers”). Dos 10% restantes, 9% vão participar pouco através das “micro-reações”, como like ou claps no medium, e apenas 1% dos internautas serão responsáveis pela maioria das discussões.

Na reportagem de Janeiro de 2012 da Revista Galileu (web archive) entrevistou uma pessoa que foi responsável por mais de CINCO MIL comentários, de forma anônima, na folha.com.

xkcd #386

Melhor escrever em português ou inglês?

A língua é uma barreira! Com isso em vista, devo escrever em português ou em inglês?

Se optar pelo inglês, possivelmente seu conteúdo vai atingir mais pessoas, mas em compensação tem muito conteúdo em inglês então fica mais difícil do seu texto se destacar.

Caso seja algo específico, como um tutorial de um framework recém lançado, talvez seja melhor fazer em inglês.

Alguns exemplos

Vou trazer alguns textos de formatos diferentes para trazer inspirações.

O primeiro exemplo é uma dica de ouro, é o texto da Anna sobre Como ativar o cancelamento de eco no PulseAudio — Anna escreve. No texto, a autora apresenta o problema (a captação de áudio do microfone embutido do notebook não funciona bem) e apresenta como atacar o problema.

Outro formato é falar sobre seu setup (um site que gosto muito de acompanhar é o manualdousuario.net).No tipo de texto como O escritório em casa da designer de UI/UX Camila,você vai falar como é o seu escritório, quais equipamentos tem e como usa. É bem divertido e ajuda quem está em dúvida do que comprar, ou até mesmo repensar a forma de trabalhar.

Para fechar os exemplos vou falar do texto do Gabriel Arruda que eu adoraria ter lido na faculdade quando estudava sobre o assunto. O texto se chama Organizando férias com otimização. A proposta é encontrar os melhores períodos para entrar de férias para ter o máximo de dias de descanso. No texto o autor fala do problema, como vai ser modelado, a linguagem MiniZinc, o código e o resultado. Atente-se em como o autor conta uma história, com começo, meio e fim, e tenha isso em mente quando estiver escrevendo seu texto.

Use memes

Uma imagem vale por mil palavras, para deixar seu textão mais atraente e prender a atenção dos leitores, use e abuse de memes!

Por exemplo se estiver escrevendo sobre como a mediana é mais uma medida mais robusta que a média a valores aberrantes (outliers), o meme abaixo encaixa como uma luva:

Entretanto em alguns contextos mais formais não pega muito bem usar memes :/ nesses casos sugiro usar outros recursos visuais como diagramas ou tirinhas como do XKCD. Uma obra prima foi o texto aqui no computando arte Métricas de Modelos Preditivos: Acurácia em Problemas de Classificação Desbalanceados | by Mikael Souza | Computando Arte

Onde escrever

O Medium é a opção mais conhecida para publicar textos. Nele seu texto é “impulsionado” para pessoas que estão na plataforma, porém a desvantagem é que ele tem um paywall que impede a leitura de mais de 5 textos por dia :/

@linhadotrem/Twitter

Uma plataforma mais focada para o público de tecnologia é o dev.to, nele os textos devem estar no formato markdown, ao passo que o Medium tem um editor próprio. Mas o dev.to não tem paywall \o/

Dependendo do seu objetivo, uma opção é escrever e publicar no próprio Linkedin. Para isso, você precisa habilitar o modo criador (instruções) então no seu perfil aparece sobre quais tópicos você escreve. Um exemplo é a Vanessa Moura (WonderWanny).

linkedin.com/in/vannessamoura

Qual plataforma devo escolher? Minha sugestão é que não se preocupe muito com isso, só comece a escrever! Mas sugiro que tenha um blog pessoal pelo menos como “backup” para não ficar refém das plataformas.

Blog pessoal

Poucas plataformas da internet sobreviveram à prova do tempo. Lembra do Orkut? Já teve um MSN? Ter um blog pessoal te ajuda a evitar isso, vou dar algumas dicas de ter um blog pessoal.

Devo usar o WordPress, Ghost, Jekyll ou Hugo? A ferramenta não importa! Só comece a escrever!

rakhim.org/honestly-undefined/19

Analytics

Quando estiver criando seu cantinho da internet, evite os analytics comerciais, principalmente o Google Analytics. O Google Analytics está presente na esmagadora maioria dos sites, tenha carinho pelos seus leitores e considere uma alternativa mais privativa.

Já ouviu que “se o produto é de graça, você é o produto”? O produto de verdade do Google Analytics são os dados de navegação dos internautas. Que tal, pelo menos no seu cantinho, experimentar opções mais privativas?

Dentre as alternativas vou destacar o goatcounter.com: é gratuito para até 100k pageviews por mês e tem a opção self-hosting.

Para quem optar pela via de hospedar por sua conta o site, tem o goaccess.io que cria dashboards apartir dos logs de acessos dos webserver como Nginx e Apache, ou seja, zero scripts de rastreamento ^_^

Usuários de RSS existem e resistem

Já falamos sobre RSS aqui no computando arte: Utilizando o RSS para “furar a bolha” | Computando Arte

O RSS é um dos principais meios dos usuários acompanharem seu site, mas fique tranquilo pois provavelmente a ferramenta do seu site já deve gerar o feed sozinho.

Só se atente que o link do feed está presente no HTML, caso contrário a pessoa vai ter que “caçar” o seu feed, por exemplo:

<link rel="alternate" type="application/rss+xml" href='https://caioau.net/blog/index.xml' title="Blogs on Pagina do caioau">

Sobre ter um domínio próprio

Vou criar um site, preciso ter um domínio? Absolutamente não precisa! Você pode usar a hospedagens gratuitas como Github Pages. Pessoalmente, prefiro o Gitlab ou até mesmo o Wordpress.

De novo, não se preocupe com isso! Só comece a escrever! Se depois de alguns meses ou anos que começou você sempre pode migrar para um domínio novo.Quando você for migrar, você pode colocar um atributo no HTML para redirecionar automaticamente para o domínio novo, o http-equiv. Por exemplo:

<meta http-equiv="refresh" content="0;url=https://caioau.net/" />

Não caia nas extensões como .xyz! Pode parecer um preço tentador, mas muitas vezes o preço só é vantajoso para registrar o domínio na primeira vez, mas quando levar em conta as renovações não vale tanto a pena assim se comparado com extensões tradicionais como .net, .com ou .org.

E um .br? O .br até que tem um preço bom, mas infelizmente no registro br seus dados pessoais (nome completo e CPF) ficam públicos no whois :/

Um .onion (onion service) cai bem

Para o seu cantinho ficar ainda mais privado você pode disponibilizar seu site em um onion service, trazendo anonimato para quem o visita com o navegador Tor.

É tranquilo fazer! A documentação é muito boa: community.torproject.org/onion-services. Dá pra facilitar ainda mais usando o onionshare.org (só apontar a pasta que fica os HTML).

Porém você vai precisar de um computador rodando 24 horas por dia para hospedar seu .onion, mas uma raspberry-pi dá conta do recado.

Último cabeçalho, prometo! Coloque no HTML o atributo http-equiv=“onion-location”, dessa forma quando o navegador Tor abrir seu site na clearnet ele vai redirecionar automaticamente para a versão disponível no .onion, por exemplo:

<meta http-equiv="onion-location" content="http://zgjjgd2o7zh4u76b5d5fpyekeif4nmbtbktufe7z4vaa6sazeraz4nyd.onion" />

/join #computando-arte

Quando estiver escrevendo seus textos é importante pedir feedbacks, dessa forma você verá como pessoas com diferentes bagagens receberão seu conteúdo, por isso ter um grupo de divulgação onde todo mundo se ajuda é muito bom!

Se gosta do nosso trabalho no Computando Arte e quiser escrever como convidado ou passar a compor o grupo, vamos te dar esse apoio! Basta nos enviar uma mensagem no twitter em @ComputandoArte ou no computando.arte@protonmail.com que iremos te responder :)

Como contêineres funcionam?

Wed, 19 Jan 2022 14:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 19Janeiro2022

Existe muito ~~hype~~ quando o assunto é contêineres e Kubernetes, isso acaba gerando uma expectativa e confusão do que são e como funcionam essas tecnologias.

Hoje vamos falar o que de fato é um contêiner, como funciona e se cria um contêiner do zero (sem o docker).

Foto de ines mills, unsplash

O que é um contêiner?

Um contêiner é um processo rodando no kernel linux. E esse processo é isolado dos outros processos/contêineres e do host (através de features do kernel).

Essa é a principal diferença dos contêineres para máquinas virtuais (VM). Todos os contêineres compartilham o mesmo kernel, no passo que cada VM tem seu kernel.

Mas se é um kernel linux, como funciona quando uso o docker no Windows ou Mac? No fundo no Windows (mesmo WSL) e Mac tem uma máquina virtual rodando o linux.

E quais são essas features do kernel que fazem tudo isso acontecer? Vamos falar delas nesse texto.

Namespaces

Namespaces controlam o que um processo/contêiner consegue ver, existem atualmente os seguintes namespaces:

Processes ID (pid)
mount points (mnt)
Network (net)
IDs do usúario e group (user)
Interprocess communication (ipc)
Control Group (cgroup)
Unix Timesharing System (uts), apesar do nome complicado, representa o hostname e domínios.

/proc

O procfs (montado em /proc) é um tipo de filesystem especial, nele existem diversas informações do sistema como CPU, memória e principalmente os processos.

Se quiser entender como ler as infos do /proc, veja em man proc.

Para que os processos do host ficarem isolados do contêiner, o contêiner precisa ter um /proc próprio (além de um namespace pid).

chroot

Para que o contêiner não acesse os arquivos do host, o chroot (change root directory) faz com que o contêiner só consiga acessar um diretório do host.

Por exemplo, se fizermos um chroot /mnt/root, um arquivo em /mnt/root/arq1.txt no host será apenas /arq01.txt no chroot. Neste chroot só consegue acessar o que está em /mnt/root

Control groups (cgroup)

:(){ :|:& };:

Provavelmente é a forkbomb mais conhecida. Uma forkbomb é um ataque que quando executada são rapidamente criados muitos processos que que se multiplicam exponencialmente incapacitando totalmente o computador, sério! Só tirando da tomada pra conseguir parar.

Precisamos de uma forma de limitar quantos recursos um determinado contêiner consegue utilizar. Os control group (cgroup) limitam os recursos como CPU, memória, rede que cada contêiner pode utilizar.

Demo: Criando um contêiner do zero

Bora criar nosso contêiner sem usar o docker! Antes de tudo precisamos instalar o que vamos precisar:

sudo apt install debootstrap cgroup-tools util-linux

Primeiramente vamos criar uma instalação base do debian, para que o que fizermos no contêiner não contamine nossa máquina (o host), rode o seguinte no terminal:

sudo debootstrap bullseye ./deb11-rootfs https://deb.debian.org/debian/

O comando acima vai criar uma instalação do Debian 11 (bullseye) na pasta deb11-rootfs.

Agora vamos criar um cgroup

export cgroup_name="cg_$(shuf -i 2000-3000 -n 1)"
cgcreate -g "cpu,cpuacct,memory,pids:$cgroup_name"

Colocando limites no cgroup:

cgset -r cpu.shares=256 "$cgroup_name"
cgset -r memory.limit_in_bytes=100M "$cgroup_name"
cgset -r pids.max=100 "$cgroup_name"

Então nosso cgroup vai ter no máximo 100MB de RAM, 1/4 de cpu (256/1024 shares) e 100 processos simultâneos então uma forkbomb vai ser contida.

É agora, bora disparar um contêiner nesse cgroup:

cgexec -g "cpu,cpuacct,memory,pids:$cgroup_name" \
    unshare --fork --mount --uts --ipc --pid --mount-proc \
    chroot "./debian11-rootfs" \
    /bin/sh -c "/bin/mount -t proc proc /proc && hostname container && /bin/bash"

Calma, muita coisa ao mesmo tempo, vamos rodar o unshare no cgroup, o unshare vai criar os namespaces que queremos (uts, ipc e pid), então fazer um chroot no debian, montar um /proc próprio, mudar o hostname para contêiner e abrir um shell bash.

Sucesso! Temos um contêiner! O que vamos fazer?

Vamos ver que o contêiner não consegue ver os processos do host, faça ps aux (para listar os processos) e veja que são apenas listados os processos do contêiner, isso aconteceu porque o contêiner está num namespace pid (veja –pid no unshare e um /proc próprio).

Mas o host consegue ver o contêiner, faça sleep 1000 no contêiner e no host faça ps aux | grep 'sleep 1000', o host consegue ver todos os contêineres, repare que os mesmos processos no host tem um pid enquanto no contêiner tem outro PID.

Veja que o contêiner só consegue enxergar seus processos, ao passo que o host (parte inferior) consegue ver os processos do(s) contêiner(s), veja também que o processo bash no contêiner tem PID 4 enquanto no host 12885.

Faça cat /proc/self/cgroup no contêiner e compare com o host, esse arquivo lista os cgroups do processo, repare que os cgroup pids,memory,cpu,cpuacct são o cgroup que criamos.

No host vá em /sys/fs/cgroup/ e navegue por exemplo em pid/nome_do_cgroup veja que tem vários arquivos informando infos e limites como pids.current e pids.max.

Por fim vamos testar esses limites, no contêiner instale o python (apt update && apt install python3) então abra o python e faça vet = int(1e9)*[None], tentamos alocar um vetor com 1 bilhão (1e9) valores, apareceu o Killed. O que aconteceu? No host faça dmesg (que exibe mensagens do kernel) e veja que o kernel (out of memory (oom)) matou processo pois ele passou do constraint.

Para facilitar coloquei os comandos que usamos para criar um contêiner em um script:

#!/bin/bash

if [ $USER != 'root' ]; then
    echo "esse script deve rodar como root, rodeo novamente com sudo"
    exit 1
fi

echo "script para demonstrar como containers funcionam (namespaces, cgroups, chroot)"

# instala dependencias, caso nao tenha instaladas descomente
echo -e "instalando as dependencias necessarias (debootstrap cgroup-tools util-linux)\n"
sudo apt update && apt install debootstrap cgroup-tools util-linux

# cria a raiz de uma instalação debian na pasta debian11-rootfs
# descomente caso nao tenha feito ainda
if [ ! -d "./debian11-rootfs" ]; then
    echo -e "\n\ninstalando o debian 11 (bullseye) na pasta debian11-rootfs\n"
    debootstrap bullseye ./debian11-rootfs https://deb.debian.org/debian/
fi

echo "criando o cgroup: "

# cria um numero aleatorio entre 2000~3000 para ter cgroup unico
cgroup_name="cg_$(shuf -i 2000-3000 -n 1)"

cgcreate -g "cpu,cpuacct,memory,pids:$cgroup_name"

cgset -r cpu.shares=256 "$cgroup_name" # 0.25 cpu
cgset -r memory.limit_in_bytes=100M "$cgroup_name" # limite de 100MB RAM
cgset -r pids.max=100 "$cgroup_name" # no maximo 100 procesos simultaneos (forkbomb prevetion)

echo -e "\n\ncgroup criado, seu nome eh: $cgroup_name"
echo -e "iniciando o container, divirta-se\n"

# calma, muita coisa ao mesmo tempo: usa o cgroup que acabamos de criar (cgexec),
#     cria namespaces novos (unshare), faz chroot e muda o hostname do container

cgexec -g "cpu,cpuacct,memory,pids:$cgroup_name" \
    unshare --fork --mount --uts --ipc --pid --mount-proc \
    chroot "./debian11-rootfs" \
    /bin/sh -c "/bin/mount -t proc proc /proc && hostname container && /bin/bash"

Overlay filesystems

No nosso exemplo usamos uma instalação do debian como filesystem, dessa forma cada contêiner precisaria ter sua própria instalação, gastando muito espaço de disco (sem aproveitar o que é comum).

Os filesystem overlay permitem que contêineres diferentes aproveitem o mesmo espaço em disco. Isso acontece através das camadas que são reutilizadas e empilhadas para criar o filesystem final de cada contêiner.

Fonte

Na figura acima temos uma visualização bacana, partimos de uma instalação do sistema operacional Ubuntu, então é instalado o java e por fim são copiados os binários da aplicação elasticsearch essa é a imagem 1 (representada na 3a camada b108…). A imagem 2 são adicionados arquivos de configuração e por fim definidas algumas variáveis de ambiente.

Cada passo é uma camada (representada à direita), aproveitando aquela ação para outras imagens que usam aquilo como base.

Features de segurança

Capabilities, seccomp e apparmor são features de segurança para restringir o que os contêineres podem fazer, vamos falar brevemente delas a seguir:

Capabilities: São permissões especiais que permitem processos fazer determinadas ações. Por exemplo cap_net_bind_service permite usar portas privilegiadas (<=1024). As capabilities surgiram para dar permissões mais granulares aos programas, antes delas essas ações só eram permitidas para o root.
seccomp-bpf: Define quais chamadas de sistema (syscalls) são permitidas.
AppArmor ou SELinux: São sistemas concorrentes normalmente distribuições baseadas no RedHat (como fedora) usam o SELinux enquanto distros baseadas no Debian (como Ubuntu, linux mint e pop-os) usam o AppArmor. Eles tem um perfil que define quais arquivos podem ser acessados (ou não) e quais capabilities são permitidas.

Quem faz tudo isso acontecer?

Quem já usa docker não precisa criar os namespaces, cgroups etc … que falamos aqui, então quem faz isso? O docker? Quem se ocupa disso são os contêiner runtime.

Fonte

O diagrama acima mostra como tudo se relaciona, ao longo dos anos foram sendo criadas interfaces padronizadas, primeiramente a OCI (open containers iniciative) em jun/2015 e nasceu o runc. Depois foi criada a CRI (contêiner runtime interface) em Dez/2016 e nasceu o containerd.

Essas interfaces foram criadas principalmente por causa do Kubernetes, e com elas sendo padronizadas esses componentes podem ser substituídos facilmente. Por exemplo, se não quiser usar o containerd você pode usar uma alternativa mais leve como o cri-o.

Lembra em 2020 que na versão 1.20 do Kubernetes que o docker não ia ser mais suportado? Isso aconteceu porque o Kubernetes interagia com o docker de uma forma não padronizada. O dockershim não era a interface padronizada CRI, então o Kubernetes tinha que manter duas implementações separadas. Mais detalhes aqui: Não entre em pânico: Kubernetes e Docker

Tem uma talk legal que conta a história dessas interfaces: Below Kubernetes: Demystifying container runtimes

Rootless

Por padrão o docker daemon (e o containerd) roda como root no host, caso um contêiner consiga escapar o isolamento isso vai comprometer totalmente o computador host.

Uma vulnerabilidade grave no runc foi a CVE-2019-5736 que permitia um contêiner escapar e ter acesso root no host.

Rootless roda o docker (e os runtimes) como um usuário não root, trazendo um avanço significativo de segurança.

Até então o modo rootless no docker era experimental, mas na versão 20.10 (lançado em dez/2020) virou estável.

Um site ótimo que fala sobre contêineres rootless é o rootlesscontaine.rs, ele explica como tudo funciona e as instruções de como usar.

Conclusão

turnoff.us/geek/linux-containers/

Vimos as primitivas do kernel Linux que fazem os contêineres funcionarem e as diferenças com máquinas virtuais, quem se interessou e quiser aprender mais vou deixar algumas referências.

Pra quem tá começando recomendo os seguintes materiais:

docker-curriculum.com: É um tutorial bem prático e completo.
Descomplicando Docker: Curso do LINUXtips em português brasileiro, a LINUXtips tem vários cursos excelentes de Devops.
Docker Mastery: É o curso que mais gosto ;) ele é bem completo e passa várias dicas para depurar os contêineres e ainda faz uma breve introdução sobre orquestração de contêineres (docker swarm e kubernetes).

Para montar esse texto usei o livro da Liz Rice: Container Security: Fundamental Technology Concepts that Protect Containerized Applications, é bem completo e quem curte segurança vai adorar. A mesma autora tem uma talk legal Building a conteiner from scratch in Go.

Primeiros passos com self-hosting

Sun, 04 Jul 2021 14:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 05Julho2021

Neste post vamos fazer uma visão geral das principais partes do self-hosting.

Foto de Jainath Ponnala, unsplash

Vai usar a nuvem? Ou apenas on-premise? Que tal ambos?

Acredito que umas das primeiras considerações quando montamos nosso setup de self-hosting é pensar como isso vai se organizar e onde vai ficar cada coisa.

Self-hosting não é ser “contra a nuvem” mas sim um movimento para ter controle dos nossos dados e aplicações que usamos, mesmo usando a nuvem nós que vamos configurar tudo e ter controle de como cada coisa funciona.

Outro modelo é hospedar “tudo em casa” (chamado de on-premise), funciona muito bem. Mas um desafio que logo vamos abordar é abrir a conexão da sua operadora para acessar seus serviços fora de casa.

Daí surge um terceiro modelo: o híbrido, parte das coisas que necessitam de velocidade ficam em casa e o restante que precisa acessar fora de casa na nuvem. No meu caso, coloco na nuvem (uma virtual private server (VPS) da digital ocean) o nextcloud com apenas meus contatos e calendário (no android uso o davx5 para sincronizar a agenda e os contatos com o nextcloud) e em casa guardo meus backups (com uma cópia no rsync.net) e todo resto :P

Além de ser muito bonito e divertido de fazer, recomendo fazer um diagrama de como vai se organizar suas aplicações e dispositivos, acima é como organizo tudo.

Hardware usado para hospedar

Para hospedar nossas coisas em casa, precisamos de um hardware para fazê-lo, pode ser usado com computador velho ou, outras opções populares, são usar a Raspberry Pi, mini pc (tipo intel NUC) ou por fim um servidor de armazenamento conectado em rede (NAS, de Network Attached Storage). Embora seja uma melhor opção pelo reuso e sobrevida de um equipamento obsoleto, é importante ficar ciente e atento a falhas por fadiga que podem comprometer a disponibilidade ou a confiabilidade do serviço.

Quando eu comecei nessa jornada do self-hosting, havia comprado um SSD para meu notebook então peguei o disco que veio nele e conectei numa Raspberry Pi. Começar com uma Raspberry Pi é ótimo: é barato, consome pouca energia e atende aos requisitos de recursos de várias aplicações.

Mas existem outras necessidades que uma Raspberry Pi não consegue atender, como por exemplo rodar máquinas virtuais, e daí surge a necessidade de outros hardwares apropriados. Como um mini-pc (ou Intel NUC) que é literalmente um mini pc e os componentes tradicionais como processador x86 (ao invés do ARM do Raspberry Pi), slots de memória RAM que pode ser trocada, etc.

NAS Synology DS920+

Quer armazenar muitos arquivos? Talvez um NAS seja mais adequado. Este equipamento conta com conexão à rede e diversos slots para colocar os discos.

Por fim, um item de hardware que é opcional mas recomendo é um “no break”, para que em caso de cair a energia na sua casa não aconteça nada.

Storage e backups

Tudo, inclusive toda forma de tecnologia, está sujeita a falhas, mas enquanto peças podem ser substituídas, arquivos perdidos podem não serem recuperáveis, por isso surge a necessidade de cópias de segurança, os famosos backups. A regra de ouro é quanto mais importante, raro ou caro mais versões e de mais difícil acesso elas devem ser.

Isso é uma consideração importante principalmente com a Raspberry Pi, os SD cards não são muito confiáveis, depois de alguns anos de uso eles acabam “morrendo”. Comigo foi muito nítido isso, teve um SD card que me serviu fielmente por 2 anos, enquanto outros logo depois de 1 ano de uso contínuo eles morreram. Mesmo adotando alguns truques para diminuir sua leitura e escrita, como montar com a flag noatime, os logs e outras pastas como tmpfs e desativar o swap.

Outra preocupação com os backups são os ataques ransomware, se seu computador teve os arquivos sequestrados, depois de sincronizar os backups também podem estar comprometidos. Por isso é aconselhável ter backups versionados, no qual teremos um “histórico” dos arquivos e no caso de um ransomware, basta restaurar a penúltima versão dos backups no qual os arquivos originais estarão lá.

Uma prática indispensável quando falamos de storage é o Redundant Array of Independent Disks (RAID: Arranjo redundante de discos baratos) que permite combinar os discos para que o sistema operacional os enxergue tudo como um disco só. Os dois modos mais básicos são o RAID 0 e RAID 1. No RAID 0 temos 2 discos que vão somar suas capacidades, enquanto no RAID 1 teremos a capacidade de apenas 1 disco e outro é usado como redundância caso um disco falhe, bastando trocar o disco quebrado que os dados serão espelhados nele.

Existem outros níveis de RAID, que são no fundo combinações do 0 e 1, como o RAID 5 (no qual teremos 4 discos, mas apenas podendo utilizar apenas o espaço de 3, pois 1 drive é usado como redundância).

A fim de combinar os discos utilizando o RAID temos diversas implementações que podem ser usadas no Linux. A mais simples é o mdadm que mapeia os drives num “disco virtual”.

Outra solução um pouco mais avançada é utilizar o LVM que é um gerenciador de volumes que permite coisas mais avançadas como diminuir e aumentar as partições usadas e realizar snapshots, que é um “retrato” do sistema de arquivos que pode ser acessado depois, dessa forma criando um “ponto de restauração”.

Por fim os sistemas de arquivos recentes como BTRFS e ZFS podem ser usados RAID e tem recursos legais como os snapshots, compressão nativa dos arquivos (dessa forma aqueles arquivos de texto como dados em csv ficam bem menor) e por fim como esses sistemas de arquivos usam o conceito de copy-on-write ou seja para toda escrita será feita uma cópia para manter a versão anterior, isso permite que para realizar a manutenção dos disco (o fsck, a checagem da integridade do sistema de arquivos) não precise desligar tudo (nesses sistemas o equivalente do fsck é o scrub).

A única ressalva para usar o ZFS e BTRFS são bancos de dados, o copy-on-write nos bancos de dados prejudica o desempenho, nesses casos talvez seja uma boa manter o sistema operacional num sistema de arquivos tradicional como ext4 e os bancos de dados nele e o armazenamento restante no ZFS ou BTRFS.

Outra preocupação é a criptografia dos discos, para proteger os arquivos em caso de furto, nesses casos é uma boa instalar o pacote dropbear-initramfs (tutorial) que permite entrar com a senha da criptografia de forma remota (por ssh), sem precisar ter um teclado in loco.

Fonte: https://twitter.com/nixcraft/status/1313909322905083905

Uma regra de ouro dos backups é a regra 3-2-1, que diz que devemos ter ao menos 3 cópias, em 2 mídias diferentes e 1 “fora de casa” em caso de incêndio. Para ter esse backup fora de casa é mais prático usar a nuvem, mas como utilizar a nuvem de forma segura? Podemos utilizar uma solução de backup que tenha criptografia, como o borgbackup, outra opção para utilizar o Google Drive, Dropbox e similares é utilizar o cryptomator.org que criptografa seus dados antes de enviá-los para a nuvem.

Partindo para as indicações, veja o vídeo do Fabio Akita: Quebrei 3 HDs: Entendendo Armazenamento explicando como os discos rígidos funcionam. E o meu texto de como montei minha solução de backups criptografados com o borgbackup e syncthing no Android: Como parei de me preocupar e passei a adorar minha solução de backups.

Como acessar meus serviços fora de casa?

Em algumas operadoras como a NET, seu modem tem um IP “interno” dentro da rede da operadora, pois os IPs IPV4 são muito escassos, o famigerado Carrier-grade NAT (CGNAT), dessa forma não é possível acessar sua casa através da internet.

Explicação sobre o NAT (fonte)

O único jeito é ligar na operadora e pedir para sair do CGNAT, permitindo assim hospedar na internet seus serviços. Foi o que fiz (tenho NET), mas não consigo abrir algumas portas como a 80 (http) e 443 (https), pois na NET isso só é permitido comprando o plano para empresas 😞

Pesquise e pergunte no /r/InternetBrasil, lá tem muito conteúdo sobre isso.

Outra questão é que os IPs não são fixos. Dentro da sua casa, quando a Raspberry Pi liga ela “pede” um IP pro seu roteador, o Dynamic Host Configuration Protocol (DHCP) que atribui um IP para a Raspberry Pi, mas os IPs muitas vezes são alocados de sequencial, ou seja nem sempre a Raspberry Pi vai ter o mesmo IP, quebrando o encaminhamento de portas do roteador. Então no roteador na configuração do DHCP atribua um IP fixo para a Raspberry Pi.

Outro IP que não é fixo é o do seu modem, que é o seu IP público na internet, infelizmente às vezes ele acaba mudando (de novo no plano para empresas o IP é fixo), daí surgem os serviços de DNS dinâmico, como o DynDNS ou NOIP, eu utilizo o duckdns e no google domínios tem a opção de DNS dinâmico.

A partir daí é só fazer os encaminhamentos de portas no seu modem, evite a opção DMZ, que expõe completamente a Raspberry Pi na internet, encaminhe apenas as portas que realmente precisa expor. Outra opção é ter um roteador próprio, e o usar o modem da operadora apenas como modem colocando no modo bridge e o seu roteador vai atuar como firewall encaminhando apenas algumas portas. Eu faço isso com meu roteador usando o OpenWRT e criei algumas VLANs (redes lógicas separadas para segregar os equipamentos) para minha rede.

Diagrama do proxy reverso (ngrok)

Outra opção é utilizar um serviço de proxy reverso, que basicamente torna seu localhost público, como ngrok, ou a solução open source pagekite.

Na mesma linha pode ser utilizada a sua VPS na cloud como proxy para acessar suas coisas em casa, pode ser algo simples como o autossh que cria tunnels ssh permitindo acessar sua casa passando pela VPS.

Ou criar uma VPN com wireguard na sua VPS e conectar sua Raspberry Pi, viabilizando seu acesso externo. O legal dessa solução é que você pode criar duas configurações no seu computador/celular: uma que usa a VPN apenas para acessar seus serviços e uma que passa todo seu tráfego pela VPN para usar em WiFis não confiáveis como WiFis públicos.

Por fim, outra possibilidade é usar o Tor, para criar um .onion que permite hospedar seus serviços em casa, sem precisar abrir suas portas, veja a documentação: onion-services.

Uma preocupação em expor seus serviços na internet é a de segurança, pois os mesmos podem ser hackeados e o hacker estará na sua rede. Isso pode ser feito de forma segura adotando as medidas de segurança que falaremos, mas outra possibilidade é utilizar o port knocking, no qual as portas dos seus serviços ficam fechadas e depois de “bater” numa sequência de portas corretas (tipo uma senha) a porta é aberta, apenas para o IP, e por um período de tempo, escondendo e protegendo seus serviços. Utilizo o knockd com o firewall ufw.

Contêiners

Os contêineres vieram para ficar e são uma maneira simples e rápida para colocar seus serviços no ar. Mas é preciso tomar cuidado em usar apenas imagens confiáveis, no fundo você está rodando um software feito por um terceiro na sua máquina.

Foram encontradas imagens maliciosas minerando bitcoin, ou imagens desatualizadas e vulneráveis. Antes de utilizar uma imagem dá uma olhada no Dockerfile no github para procurar por coisas suspeitas.

Imagens oficiais do dockerhub são confiáveis, outra fonte excelente de imagens é o LinuxServer.io com diversas imagens ótimas.

Partiu para as indicações? Tem um site excelente para aprender docker, bem direto ao ponto o docker-curriculum.com, curso eu indico o docker-mastery na udemy que até fala um pouco de clusters com docker swarm e kubernetes, por fim no youtube tem o vídeo excelente da TechWorld with Nana Docker Tutorial for Beginners.

Proxy Reverso

Quando vamos hospedar diversos serviços uma construção comum que é utilizada é o proxy reverso, com ele quando vamos acessar nossos serviços evitamos de ter que usar uma porta diferente para cada coisa, dessa forma podemos configurar o proxy reverso para como cada serviço vai ser acessado, normalmente por um subdomínio tipo nextcloud.seu-dominio.tld ou como uma subpasta seu-dominio.tld/nextcloud.

Ilustração de um proxy reverso

As opções mais populares são o Secure Web Application Gateway (swag), da linuxservers.io, que é um nginx, com let’s encrypt (para ter o https) e fail2ban (que bloqueia bots e IPs que estão tentando te invadir).

A outra opção é o traefik que tem a vantagem de já ser integrado com o docker e kubernetes, dessa forma ao invés de configurar as “rotas” de cada serviço em arquivos de configuração (como é feito no nginx) as configurações vivem nos labels do contêiner de cada serviço, muito mágico ✨

Aliado com o proxy reverso, podemos utilizar o authelia, que permite ter o mesmo usuário e senha (single sign-on) sincronizado com todos seus serviços e autenticação em 2 fatores integrada em todos seus serviços, tornando tudo mais prático e seguro.

Bora para um exemplo?

version: "2.1"

services:

  traefik:
    image: "traefik:v2.4"
    container_name: "traefik"
    restart: unless-stopped
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  whoami:
    image: "containous/whoami"
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=PathPrefix(`/whoami/`)"
      - "traefik.http.routers.whoami.entrypoints=web"

  bitwarden:
    image: bitwardenrs/server
    container_name: bitwarden
    restart: unless-stopped
    #environment: 
    #- SIGNUPS_ALLOWED=false
    volumes:
      - ./docker_vols/bwdata/:/data/
    labels: 
      - "traefik.enable=true"
      - "traefik.http.routers.bitwarden.rule=PathPrefix(`/vault/`)"
      - "traefik.http.routers.bitwarden.entrypoints=web"
      - "traefik.http.middlewares.bw.stripprefix.prefixes=/vault/"
      - "traefik.http.routers.bitwarden.middlewares=bw"

Esse é um arquivo docker-compose, é um arquivo yaml que define vários contêineres, no fundo é como se o fizesse vários docker run, um para cada contêiner.

Para executá lo, basta baixar esse arquivo como docker-compose.yml e rodar o docker-compose up -d

Temos 3 contêineres definidos: o traefik, o whoami (usado para debugar o traefik) e o bitwarden (gerenciador de senhas). Repare como as “rotas” para o traefik estão definidas nos labels de cada contêiner ✨

Espere um pouco e vamos testar tudo: abra seu navegador no endereço localhost/whoami/ , e veja a rota para o whoami funcionando. Depois vá para localhost/vault/ e acesse o bitwarden. Por fim localhost:8080 e veja o dashboard do traefik (não se esqueça de colocar uma senha depois).

No bitwarden, repare na parte volumes, aqui os dados da aplicação serão salvos na pasta docker_vols/bwdata, para ser feito o backup.

No traefik, veja em volumes: /var/run/docker.sock:/var/run/docker.sock:ro, isso vai “conectar” o docker no contêiner do traefik, fazemos isso para que o mesmo consiga “mapear” os outros contêineres e ler suas regras de roteamento em suas labels. Tome cuidado e só faça isso com contêineres que confia pois isso pode dar a permissão de acessar e comprometer os todos seus contêineres e seu computador.

Por fim repare que todos os contêineres têm restart: unless-stopped, isso é a política de restart do docker, dessa forma caso o computador seja desligado quando for ligado os contêineres serão iniciados automaticamente, unless stopped, ou seja a menos que sejam parados.

Ultimo exemplo:

version: "2.1"

networks:
  web:
    external: true
  internal_net:
    external: false

services:

  traefik:
    image: "traefik:v2.4"
    container_name: "traefik"
    restart: unless-stopped
    networks:
      - web
    command:
      #- "--log.level=DEBUG"
      - "--api.insecure=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  ttrss:
    image: wangqiru/ttrss:latest
    container_name: ttrss
    restart: unless-stopped
    networks:
    - internal_net
    - web
    environment:
      - DB_PASS=E7WaTdu9KPLXxYXTqtrA
      - SELF_URL_PATH=http://localhost/
      - DB_HOST=ttrss_db
      - PUID=1000
      - PGID=1000
      - TZ=America/Sao_Paulo
    depends_on:
      - ttrss_db
    labels: 
      - "traefik.enable=true"
      - "traefik.http.routers.ttrss.rule=PathPrefix(`/ttrss/`)"
      - "traefik.http.routers.ttrss.entrypoints=web"
      - "traefik.http.middlewares.sp1.stripprefix.prefixes=/ttrss/"
      - "traefik.http.routers.ttrss.middlewares=sp1"
      - "traefik.docker.network=web"

  ttrss_db:
    image: postgres:13-alpine
    container_name: ttrss_db
    restart: unless-stopped
    networks:
      - internal_net
    environment:
      - POSTGRES_PASSWORD=E7WaTdu9KPLXxYXTqtrA
    volumes:
      - ./docker_vols/ttrss_db/:/var/lib/postgresql/data
    labels:
      - "traefik.enable=false"

Continuamos com o nosso conhecido traefik, mas agora vamos colocar no ar o tt-rss, que é um leitor de feeds RSS, que utiliza um banco de dados postgres, essa é a primeira coisa diferente nesse exemplo repare que no topo estão definidas 2 redes (uma chamada web e outra internal_net). O traefik que é o contêiner que está exposto está apenas na web, a aplicação (ttrss) em ambas as redes e o banco de dados apenas na internal_net. Fizemos isso para segregar o banco de dados (que contêm dados sensíveis) do traefik para que o mesmo caso comprometido não acesse o(s) banco de dados.

Outra coisa a destacar é a opção depends_on, que cria um relação de dependência entre o contêiner da aplicação (ttrss) e o seu banco de dados, iniciando o banco de dados antes da da aplicação.

Segurança

A fim de manter tudo isso seguro, existem diversas práticas e níveis de segurança, um bom começo é ter senhas fortes e únicas (evitar o famoso usuário admin com senha admin) com um gerenciador de senhas e realizar as atualizações de segurança.

Para deixar todos seus contêineres atualizados, tem o Diun, que “conecta” no docker (como fizemos com o traefik) e verifica periodicamente se existem atualizações para seus contêineres, disparando uma notificação via email ou telegram etc …

Já para manter o host atualizado, uma possibilidade é utilizar o UnattendedUpgrades que atualiza os pacotes automaticamente, e se quiser pode até reiniciar automaticamente quando necessário. Porém, talvez seja melhor assinar as listas de email/rss de segurança da sua distro (debian security-announce, Ubuntu USN), do docker e das suas aplicações e frameworks e veja se faz aquelas atualizações de fato te afetam e se realmente faz sentido aplica-lás.

https://twitter.com/nixcraft/status/878903460871061504

Um site excelente para deixar nos favoritos é o Open Web Application Security Project (owasp) é uma comunidade de segurança com diversas dicas e recomendações, por exemplo: como armazenar senhas de forma segura e no nosso caso Docker security.

Uma forma excelente para aprender segurança é praticar nas Capture the flag (CTF) que são ambientes controlados para testar a segurança como um todo e revelar a flag (tipo uma senha), comprovando que conseguiu comprometer a segurança. Tem vários sites, tenho mais contato com o overthewire e o hackthebox.

Um vídeo que gostei foi do LiveOverflow: Protect Linux Server From Hackers, no qual ele disseca as dicas populares de boas práticas para proteger seus servidores linux e ele mostrou que essas boas práticas nem sempre são tão positivas e “preto no branco”. Depois ele fez uma continuação bem interessante: Understand Security Risk vs. Security Vulnerability! pontuando as diferenças e semelhanças entre riscos de segurança e vulnerabilidades.

Monitoramento

Na seção anterior sobre storage, como saberemos se um disco falhou? Quando tudo parar de funcionar? Ou tem algum jeito de “ficar de olho”, por isso que precisamos ter uma solução de monitoramento.

As soluções mais populares de monitoramento são o zabbix e o prometheus, que depois de configurados te notificam em caso de alguma falha.

No caso dos discos, temos dois indicativos que os discos estão para falhar: As informações S.M.A.R.T. – Self-Monitoring, Analysis, and Reporting Technology (tecnologia de automonitoramento, análise e relatório) geradas pelo próprio disco com diversas informações da “saúde” do disco, o disco não gera isso sozinho, sua solução de monitoramento precisa disparar os auto-testes e monitorar essas infos. Porém um estudo de 2007 do Google, mostrou que os dados S.M.A.R.T sozinho não são um bom indicativo da falha dos discos, daí surgem o segundo indicativo o tempo de escrita e leitura, se o disco começa a demorar muito para ler ou escrever isso pode indicar uma falha, essa informação é gerada na solução de monitoramento.

Outra solução legal de monitoramento é o healthchecks.io, serviço para monitorar seus cronjobs (tarefas executadas periodicamente), por exemplo imagine que você configurou para fazer backup do seu laptop na sua Raspberry Pi, mas por algum problema o backup para de ser feito com sucesso. Como vai saber que parou de funcionar? No healthchecks.io você configura uma periodicidade que os backups devem ser feitos e quando é feito o backup seu laptop “pinga” o serviço, e em caso de falha ou o backup deixou de rodar uma notificação é enviada.

Infraestrutura como código

Essa é a parte mais legal 🤩, chegou o dia que seu SD card da Raspberry Pi morreu 😞 , tranquilo só fazer a restauração do backup no SD novo e instalar e configurar tudo mas isso pode ser demorado, com a infraestrutura como código (IaC) você cria uma “receita” que configura toda sua infra automaticamente.

A ferramenta que tenho mais contato é o ansible, ele é similar ao chef e puppet. A principal vantagem do ansible é que ele é agentless, ou seja não precisa de um ter software instalado esperando por instruções do controle, basta ter o python instalado e acesso ssh e na máquina que vai disparar o ansible basta instalar com um pip install, super prático.

Apesar de ser muito legal automatizar a configuração dos ambientes com IaC, se tudo é importante nada é importante, a IaC não precisa estar no topo das suas prioridades quando configurando seu setup.

Considerações finais

Espero com essa visão geral dos aspectos do self-hosting tenha uma noção do que se trata e comece a aprender mais sobre o tema e adotar esse movimento.

Além de todas indicações que já fiz vou fechar indicando um podcast: o Self-Hosted podcast que me ajudou muito a aprender sobre esses tópicos e o canal do YouTube: Techno Tim que tem várias dicas de como montar seu homelab.

O que é selfhosting e por que adotá-lo

Fri, 28 May 2021 16:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 28Maio2021

Muitos dos serviços digitais que utilizamos no nosso dia a dia estão na “nuvem”, como Gmail, LinkedIn, Google Drive/Docs etc … e como diria um famoso ditado “essa tal de “nuvem” não existe, são apenas computadores de outras pessoas”. Mas, então quais as implicações da maioria das nossas vidas digitais estar nesses computadores dessas grandes empresas? Essas implicações no geral são positivas para os usuários?

Neste texto, que vai ser o primeiro de uma série, vamos falar de uma alternativa simples chamada self hosting, ou seja, hospedar os serviços que usamos em computadores que de fato temos controle, e como fazê-lo.

Motivos para adotar o self-hosting

Dentre todos os motivos para adotar o self-hosting, vale destacar os seguintes:

Segurança

Com muita frequência, vemos notícias de vazamentos envolvendo nossos dados, e mesmo assim muitos dos vazamentos não são percebidos pelas próprias empresas e logo não são noticiados, ou seja, a quantidade de vazamentos pode ser ainda maior.

Hospedando as próprias coisas não é um alvo tão grande para os cibercriminosos quanto das big tech, pense nos incentivos, se comprometer uma big tech o cibercriminoso vai ter os dados de milhões de pessoas , enquanto comprometer sua pequena infra não rendera tanto dados assim. Além disso outro incentivo para atacar as big tech é que muitas delas tem programas de bug bounty para recompensar a descoberta da suas inseguranças.

E também isso vai te ensinar quais são as boas práticas de segurança e como adota-lá.

Privacidade

Outro ditado famoso diz que se o serviço é gratuito, o produto é você. E isso é verdade, você está pagando o serviço com seus dados.

Com selfhosting, seus dados ficam apenas com você, retomando totalmente sua privacidade, afinal foi você quem montou o esquemas de criptografia de disco, gerenciamento de senhas (afinal como as senhas sempre vazam não pode usar a mesma senha em mais de um lugar, é bom se inscrever no haveibeenpwned.com para ser notificado se suas senhas vazaram)

Aprendizado e experiência

Pra min essa é a principal vantagem, hospedar suas próprias coisas vai proporcionar um conhecimento e experiência enorme em diversas disciplinas como:

Sistemas operacionais (principalmente Linux e talvez BSD).
Redes
Segurança
Contêineres
Linguagens de script
Infraestrutura como código
Monitoramento
E principalmente Inglês

Ter o seu “ambiente controlado” vai te possibilitar aprender, testar e quebrar as coisas que te proporcionará um aprendizado enorme que num ambiente profissional do trabalho muitas vezes não te permitiria.

Exemplos de aplicações

As aplicações mais comuns que normalmente são hospedadas são:

Pi-Hole: Permite bloquear anúncios, domínios que te rastreia e maliciosos a nível de rede, ou seja em todos seus dispositivos não apenas no navegador.
syncthing: É um app pra Android no PC que permite sincronizar pastas do seu android com o PC e vice versa. Dessa forma você consegue fazer backup do seu celular e sincronizar arquivos sem precisar de uma nuvem das big tech. Se tiver interesse leia meu texto de como montei meu setup de backups: Como parei de me preocupar e passei a adorar minha solução de backups.
nextcloud: É uma solução de nuvem completa, permite sincronizar arquivos como dropbox, sincronizar contatos e agenda, quadro kanban (tipo trello), videochamadas e muito mais.
Home Assistant: Gosta da sua alexa ou google assistant controlando suas luzes e outras coisas da sua smart home? Com o Home assistant você consegue ter seu próprio hub de automação com total privacidade e controle. Gosta de eletrônica? O projeto esphome consegue integrar suas plaquinhas ESP8266/ESP32 com o Home Assistant.

Considerações finais

Com o selfhosting você terá privacidade e controle total dos seus dados e vai aprender muito nessa jornada, nós próximos textos vamos abordar de fato começar.

Vale uma pequena ressalva, casos você seja uma pessoa dev e só quer colocar seu app no ar, e seu objetivo principal agora é apenas isso, talvez ir pelo caminho do selfhosting não seja a melhor alternativa agora, administração de sistemas é muitas vezes um trabalho de tempo integral e talvez seja melhor usar serviços como heroku, vercel e netlify que cuidaram de tudo para você, para que consiga fazer essa entrega mais rápido. E quanto tiver disponibilidade estudar e adotar o selfhosting :P

Utilizando o RSS para "furar a bolha"

Tue, 27 Apr 2021 13:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 27Abr2021

Já percebeu que o seu feed da rede social está cheio de notícias que fazem você “passar raiva”? O fenômeno é chamado de doomscrolling, e apesar que de termos mais notícias desse tipo, as redes sociais as exibem com mais frequência.

A conhecida “bolha” (filter Bubble) das redes sociais faz com fiquemos mais tempo nas redes, exibindo apenas posts que engajamos mais, e isso está causando diversas consequências nefastas desde potencializar fake news e desinformação a ansiedade e depressão nos internautas.

Mas se eu te disser que existe uma alternativa? Um meio de receber as informações diretamente, sem nenhum filtro ou algoritmo. É disto que vamos falar hoje, o RSS.

Logo do RSS

O que é o RSS?

RSS é a sigla para Really Simple Syndication, sincronização realmente simples, é um arquivo XML gerado por muitos sites que exibe os posts que o site tem, dessa forma a pessoa com um leitor de RSS consegue acompanhar diversos blog, sites de noticia e etc … centralizados no seu leitor.

Quem criou o RSS?

Uma das pessoas responsáveis pela criação do RSS foi o Aaron Swartz, um hacker conhecido por diversas coisas como o Creative Commons e da melhor rede social o Reddit 😛

Aaron Swartz (2008), Fonte: wikimedia

Quem se interessou pela historia do Aaron recomendo os seguintes conteúdos:

O documentário: O Menino da Internet: A História de Aaron Swartz: LibreFlix
E pra quem gosta de podcast Engenharia Reversa #1: Aaron Swartz, a história do ativista e co-criador do Reddit e do RSS

Como usar o RSS? Parte 1: Os leitores

Para usar o RSS você precisa de um leitor de RSS, e não faltam opções! A primeira classe de leitores são os locais, um app local no seu computador ou celular que infelizmente não sincroniza entre seus dispositivos, se isso não é um problema para você é uma ótima opção.

O thunderbird (cliente livre de emails) é a opção mais tradicional.

Gosta de programas que rodam no terminal? tem o newsboat.

Para Linux tem o liferea que está disponível na maioria das distribuições.

No Android tem o Feeder, que também está disponível na Fdroid (loja de aplicativos livres).

Tem Mac ou iOS? Uma opção ótima é o NetNewsWire.

Depois desse monte de opções, se não quiser instalar nada 😛 tem o Feedbro extensão para os navegadores (chrome e firefox).

Essas são todas as opções de leitores locais que conheço.

Vamos agora para as opções online, que permitem sincronizar entre seus dispositivos, é muito prático pois se viu algo interessante no computador pode marcar para ler depois no celular e vice versa.

O Feedly é o serviço mais conhecido, tem um plano básico gratuito, bem amigável, para quem está começando recomendo ir com ele.

Captura de tela do Feedly

Por fim, a opção que eu uso, para quem gosta de software livre e se preocupa com sua privacidade, o Tiny Tiny RSS (tt-rss.org). Você pode instalar numa raspberry-pi e acessar na sua rede local (caso precise acessar fora de casa pode usar serviços como Pagekite e ngrok para torna-ló acessível pela internet) ou alugar uma cloud e hospedar lá.

Outra opção para usar o tt-rss é utilizar a instancia do Snopyta (grupo sustentado por doações que hospeda diversos softwares livres).

Como usar o RSS? Parte 2: Assinando os feeds

Com um leitor de RSS da sua preferencia funcionando, bora assinar os feeds!

Vamos começar pelo YouTube, os feeds são assim:

www.youtube.com/feeds/videos.xml?channel_id=<id_do_canal>

Substitua no final pelo channel_id do canal que quer assinar. Um truque para descobrir o id que tem interesse: Selecione um vídeo, em seguida clique no ícone do canal e daí o channel_id vai aparecer na url. Por exemplo, o feed do canal da Jana Viscardi é o seguinte:

www.youtube.com/feeds/videos.xml?channel_id=UC9h2vDtQXEiD0O4aVubsYYA

Caso o truque não funcione, com o vídeo aberto, abra o código fonte da página (use o atalho control+u) e procure (control+f) por channelId.

Para acessar os feeds da melhor rede social 😛, o Reddit:

Na wiki tem uma seção sobre RSS, basta colocar um .rss no final. Por exemplo o feed do /r/dataisbeautiful é:

old.reddit.com/r/dataisbeautiful/.rss

Precisa acompanhar projetos do github? Por exemplo, utilizo aqui em casa um firmware livre no meu roteador, o OpenWRT, para acompanhar as releases o feed é:

github.com/openwrt/openwrt/releases.atom

No mesmo padrão para acompanhar os commits, da branch master:

github.com/openwrt/openwrt/commits/master.atom

Obs.: Os feeds atom na prática são a mesma coisa que feeds RSS, alguns sites adotam isso.

Gosta de Newsletters? O serviço kill-the-newsletter.com cria um e-mail para você cadastrar na newsletter e um feed para assinar.

Veja o diretório de Newsletters brasileiras que o manual do usuário fez.

Gosta do medium? o feed é assim: medium.com/feed/nome-do-usuario, por exemplo, o feed do computando arte 🤭 é:

medium.com/feed/computando-arte

E o Twitter? Infelizmente o twitter descontinuou os seus feeds RSS 😞 Mas tem um software livre chamado Nitter que permite navegar pelos posts do twitter com privacidade e gerar um feed rss.

Tentei mostrar como chegar nos feeds de alguns serviços populares, mas e os outros? Então muitos sites e podcasts tem o ícone e/ou o link do seu feed, caso não encontre procure no código fonte da pagina por rss ou feed ou xml ou atom e você vai acabar encontrando. A maioria das tecnologias por trás dos sites como o super popular WordPress gera nativamente os feeds RSS.

Por exemplo, até meu site pessoal simples uso o Hugo (gerador de sites estáticos, semelhante ao Jekyll) e coloquei o link pro meu feed, mas se for procurar no código fonte da página encontrará:

<link rel="alternate" type="application/rss+xml" href='https://caioau.net/blog/index.xml' title="Blogs on Pagina do caioau">

Pronto, aqui você encontra o meu feed RSS:

caioau.net/blog/index.xml

Por fim, não poderia fazer um texto sobre RSS sem falar do RSS-Bridge, software livre que gera feeds RSS apartir de páginas do facebook, instagram (dá até pra seguir hashtags ✨) , Wikipedia e várias outras integrações.

Considerações finais

Com o RSS podemos “furar a bolha” e receber toda a informação sem filtros e algoritmos. Usando o RSS logo vai perceber uma das razões (além do lucro das big tech 💸) do porque desses filtros, é muita informação! Então use com moderação (para evitar o famoso FOMO, fear of missing out, a sensação de que não posso ficar minutos longe do meu celular pois estou perdendo algo) e tentar uma relação mais saudável com a tecnologia.

Vale recomendar o episódio #41 do tecnocracia, é um podcast excelente sobre as consequências da tecnologia e vou indicar justamente o ep. #41: Manual prático para retomar sua atenção do calabouço das redes sociais com várias dicas 🧘🔕 de como controlar o celular e as redes sociais e não o contrário.

Estamos usando a tecnologia? Ou sendo usados? (Fonte)

Por fim, pra quem gosta do tema, vou indicar alguns conteúdos muito interessantes 🤯

Crédito: Cryptorave no twitter

O documentário Dilema nas Redes (2020), disponível na Netflix, bombou! Adoro como ele é muito didático e expões as principais questões do tema, recomendo muito pra quem ainda não viu. Outro doc, é o Coded Bias (2020) que foca mais nas tecnologias de reconhecimento facial e seus vieses e contou com a presença da Cathy O’Neil, autora do livro fenomenal Weapons of Math Destruction traduzido no Brasil como Algoritmos de Destruição em Massa.

Uma talk recente, que eu adorei foi a Rage Against The Machine Learning, onde o Dr. Hendrik Heuer fala da sua pesquisa de auditoria dos algoritmos das redes sociais para o interesse público.

Para podcast, vou indicar outros episódios do tecnocracia, é difícil indicar só alguns, todos são ótimos:

Precisa transferir um arquivo? O magic-wormhole vai mudar sua vida!

Mon, 19 Apr 2021 14:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 19Abr2021

Já precisou transferir um arquivo para alguém pela internet e não foi fácil chegar numa solução fácil? O magic-wormhole pode ser uma excelente alternativa!

XKCD #949: File transfer

Esse XKCD ilustra bem a motivação do magic-wormhole, a fim de copiar um arquivo para outra pessoa, algumas vezes sites como Dropbox não são a melhor opção, e como muitas vezes não se pode encontrar fisicamente para ser via um “pendrive” (principalmente com uma pandemia 😷) o magic-wormhole cria um “túnel mágico” para te salvar✨

Como usar

O magic-wormhole é um programa em python para ser usado no terminal, então se você já tem o python instalado basta instalá-lo com o pip:

pip install magic-wormhole

Uma vez instalado de ambos os lados (quem envia e quem recebe), basta rodar o comando wormhole send seguido do nome do arquivo:

$ wormhole send arquivo_a_ser_enviado
Sending 45 Bytes file named 'arquivo_a_ser_enviado'
Wormhole code is: 6-wichita-reindeer
On the other computer, please run:
wormhole receive 6-wichita-reindeer

Agora, quem vai receber deve digitar wormhole receive seguindo do código gerado (6-wichita-reindeer).

É isso! Como mágica o arquivo é enviado como mágica 🤩

Como funciona o magic-wormhole?

Sem entrar muito em detalhes, o magic-wormhole funciona em 2 partes: a descoberta e o envio em si.

A pessoa que vai enviar o arquivo roda o wormhole send.
É gerado um código (ex.: 6-wichita-reindeer), pelo servidor mailbox do magic-wormhole.
Quando o cliente entra com o código, a pessoa que envia e a recebe conseguem “se encontrar”.
É tentado uma conexão direta, entre as duas pessoas, se estiverem na mesma rede local vai funcionar e ser muito rápido, caso contrário o magic-wormhole intermedia a conexão através do seu servidor de transito (a conexão sempre é criptografada).

Quem tiver interesse para aprender profundamente como funciona veja a palestra do Brian Warner, o autor original do projeto na PyCon 2016.

Outro programa excelente que funciona de uma maneira similar, mas para outro proposito é o Syncthing, que permite sincronizar os arquivos entre seus dispositivos, criando sua “nuvem privada” somente com seus dispositivos.

O que é um tarpit de rede e como colocar um no ar

Mon, 18 Jan 2021 13:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 18Jan2021

Foto de Ariel Besagar, Unsplash

Quando vemos as notícias de cyber ataques, como o WannaCry, é impressionante o impacto desses ataques, infectando milhares de computadores. No caso do WannaCry existia uma atualização de segurança que foi publicada 1 mês antes do ataque, quem não atualizou e estava exposto na internet provavelmente foi infectado. Moral da historia é deve se tomar todas precauções de segurança antes de expor algum computador na Internet. Se tiver interesse, leia as essas estatísticas:

Assim que se coloca algum serviço na internet pública, em poucos minutos, já vemos que os logs de acesso do ssh (protocolo para acessar remotamente computadores) estão lotados de tentativas de combinações de usuário e senha, para conseguir acesso no servidor. Neste texto vamos mostrar como se proteger e como colocar um tarpit no lugar, uma especie de “armadilha” que deixa os atacantes “parados” perdendo tempo e recursos sem atacar ninguém, protegendo quem está vulnerável.

Logs de acesso do ssh: Fonte

Começando pelo começo: protegendo seu servidor ssh

De todas as mitigações para proteger seu servidor ssh, a medida mais efetiva é desativar a autenticação por senha e utilizar apenas a autenticação por chaves privadas. Se ainda não tem uma chave ssh, gere uma com o comando ssh-keygen.

Copie sua chave pro seu servidor: ssh-copy-id -i ~/.ssh/id_rsa usuario@servidor, se necessário ajuste o caminho da chave depois do -i .
Teste se está funcionando: ssh usuario@servidor , se o ssh conectar sem pedir senha então está tudo certo.

Desativando autenticação por senha: logue no servidor (ssh usuario@servidor), e edite o arquivo /etc/ssh/sshd_config como root (sudo nano /etc/ssh/sshd_config), por fim encontre a linha PasswordAuthentication e coloque no, não se esqueça de não deixar a linha comentada (tire o # no começo da linha). Por fim, reinicie o ssh, sudo systemctl restart sshd

Testando: Tente logar com um usuário que não existe: tipo ssh usr123321@servidor, e deve aparecer Permission denied (publickey).

É isso que vai acontecer com quem tentar acessar seu servidor, uma permissão negada sem nem pedir senha.

endlessh: O que faz um tarpit?

A tradução de Tarpit é “poço de areia movediça”, no nosso contexto de redes é um serviço que intencionalmente insere um atraso, atrasando os clientes que estão conectando e os forçando esperar.

O endlessh é um tarpit de ssh, ele explora um “brecha” na especificação do ssh (RFC 4253) que diz que quando um cliente está conectando o servidor pode mandar um “banner” (aqueles avisos legais avisando a politica de segurança), mas a especificação não coloca um limite do tamanho desse banner. É assim que o endlessh funciona, um cliente conectando fica esperando mandar o resto do banner, e o endlessh fica mandando o banner de pouco em pouco só pra manter a conexão ativa. Dessa forma o atacante fica gastando banda e recursos sem acontecer nada ao invés de atacar os clientes que de fato estão inseguros.

Exemplo de banner ssh, Fonte: https://www.healthcareitnews.com/news/warning-banners-often-work-heres-how-hospitals-can-use-them-ward-hackers

Colocando o endlessh no ar

Primeiramente vamos instalar as dependências necessárias:

sudo apt install git build-essential

O apt , ou similarmente apt-get, é um gerenciador de pacotes de distribuições Debian. Pense no gerenciador de pacotes como a app store de seu celular, um programa que instala, remove e atualiza os softwares do seu sistema. É uma maravilha, pois imagine que precisa atualizar o VLC, ao invés de ir ao site e baixar o instalador mais recente basta fazer sudo apt update, para verificar se existem atualizações e finalmente sudo apt upgrade para baixar e instalar as atualizações.

O comando acima então instala o git e o pacote build-essential.

Para saber o que um pacote é, podemos utilizar o info do apt, com apt into build-essential temos:

Package: build-essential
Version: 12.9
Priority: optional
Build-Essential: yes
Section: devel
Maintainer: Matthias Klose <doko@debian.org>
Installed-Size: 20.5 kB
Depends: libc6-dev | libc-dev, gcc (>= 4:10.2), g++ (>= 4:10.2), make, dpkg-dev (>= 1.17.11)
Tag: devel::packaging, interface::commandline, role::data, role::program,
 scope::utility, suite::debian
Download-Size: 7,704 B
APT-Manual-Installed: yes
APT-Sources: <https://deb.debian.org/debian> bullseye/main amd64 Packages
Description: Informational list of build-essential packages
 ...
 This package contains an informational list of packages which are
 considered essential for building Debian packages.  This package also
 depends on the packages on that list, to make it easy to have the
 build-essential packages installed.
 ...

Instalamos o build-essential pois ele instala o compilador gcc e o make que vamos utilizar (veja na linha Depends).

Clonando o projeto:

git clone https://github.com/skeeto/endlessh.git

Agora precisamos compilar o projeto. Felizmente o projeto tem um makefile, que é um arquivo com os comando de compilações configurados. Dessa forma basta fazer make e sudo make install para gerar o binário do endlessh e copiar para /usr/local/bin.

Agora pasta rodar o endlessh:

/usr/local/bin/endlessh -v

2021-01-14T01:22:10.091Z Port 2222
2021-01-14T01:22:10.091Z Delay 10000
2021-01-14T01:22:10.091Z MaxLineLength 32
2021-01-14T01:22:10.091Z MaxClients 4096
2021-01-14T01:22:10.091Z BindFamily IPv4 Mapped IPv6

O endlessh está rodando na porta 2222, então abra outra aba no terminal e faça ssh usuario@servidor -p 2222 e veja o que acontece … ou seja nada 😆

Mas como faço pro endlessh iniciar sozinho? Na próxima secção vamos mostrar como :)

systemd: Como manejar serviços

O systemd é um sistema init, que é o primeiro processo iniciado durante o boot do sistema e ele é responsável por iniciar e gerenciar todos os serviços do sistema. Por exemplo, se está rodando um servidor web com nginx, o systemd vai iniciar o nginx automaticamente e em caso dele travar vai ser iniciado novamente, certificando-se que está sempre no ar.

Na maioria das distribuições Linux, o systemd é o sistema init padrão, que é controlado através do comando systemctl. Por exemplo: veja o status de todos os serviços: sudo systemctl status --all . aqui podemos ver a que serviço cada processo está associado.

Mão na massa: na pasta util do endlessh temos o arquivo para subir o endlessh como serviço, o endlessh.service (dentro da pasta util). Não vamos entrar no detalhe das diretivas definidas desse arquivo, aos interessados veja o artigo sobre systemd na arch wiki.

Vamos apenas mudar apenas uma coisa no arquivo, na linha exec coloque o -v, para ele rodar mostrando mais detalhes, como os exibir os clientes conectando, ficando assim: ExecStart=/usr/local/bin/endlessh -v

Vamos copiar o arquivo para ser identificado: sudo cp endlessh.service /etc/systemd/system/, agora faça sudo systemctl daemon-reload para que seja reconhecido, e então finalmente sudo systemctl enable endlessh, agora o endlessh está habilitado e deve iniciar automaticamente, para iniciá-lo agora faça sudo systemctl start endlessh.

Só para ter certeza, faça sudo systemctl status endlessh. Podemos ver o status do serviço

Como queríamos, o serviço está rodando.

Também podemos reiniciar o serviço com restart (sudo systemctl restart endlessh), e stop para parar. Para desativar temos o disable, porém caso o serviço seja dependência de outro serviço ele pode acabar sendo iniciado. Nesses casos utilize o mask que previne que o serviço seja iniciado. Por fim, temos o reload que faz que com o serviço carregue sua nova configuração sem derrubar o serviço.

journalctl: Acessando os logs

Agora que o endlessh está rodando e é iniciado automaticamente, como faço para acessar a saída dele para vem quem está conectando?

No systemd os logs de todos serviços podem ser acessados através do comando journalctl, faça sudo journalctl e veja os logs de todos serviços, inclusive do kernel.

Para vermos apenas do endlessh: sudo journalctl -u endlessh

logs do endlessh

Bora analisar os dados? 🤓

Podemos pegar a saída do journalctl e jogar num arquivo para ser lido e parseado para ser colocado num dataframe, por exemplo.

para fazer isso, basta rodar o comando:

journalctl -u endlessh.service > /tmp/endlessh.log

Dessa forma os logs estarão em /tmp/endlessh.log. Depois disso basta fazer um programa que lê o arquivo, para fazer suas análises. Mas né, sem tempo irmão 😛. Vamos pela solução simples, usar comandos de processamento de texto, do Unix ✨:

sudo journalctl -u endlessh --since 2021-01-15 --until 2021-01-16 | grep CLOSE | wc -l
1044

Da mesma forma que o operador > joga a saída pra um arquivo o | (chamado de pipe) redireciona a saída para o outro comando, dessa forma o commando acima conta quantas linhas CLOSE tinha. Ou seja no período de 1 dia tivemos 1044 conexões.

sudo journalctl -u endlessh --since 2021-01-15 --until 2021-01-16 | grep CLOSE | awk '{print $8}' | sort | uniq -c | sort -hr
    
    705 host=::ffff:218.92.0.210
     32 host=::ffff:87.251.77.206
     12 host=::ffff:81.161.63.103
     10 host=::ffff:221.181.185.220
      9 host=::ffff:81.161.63.100
      9 host=::ffff:222.187.222.53
      9 host=::ffff:221.181.185.148
      8 host=::ffff:221.181.185.135
      8 host=::ffff:122.194.229.122
      7 host=::ffff:218.92.0.211
      6 host=::ffff:81.161.63.252
      6 host=::ffff:81.161.63.101
[...]

O comando acima mostra os IPs que fizeram mais conexões.

Conclusão

Neste texto aprendemos como proteger seu servidor ssh, dessa forma ninguém não autorizado vai conseguir acessar seu servidor. E mostramos como colocar no ar um tarpit para ajudar a proteger quem ainda está vulnerável. Além disso aprendemos como manejar serviços e fazer processamento de texto de uma forma bem rápida, usando ferramentas Unix, que são tarefas muito importantes na administração de sistemas.

Como continuação dessa jornada de implementar as boas praticas de segurança, sugiro o seguinte tutorial da DigitalOcean: 7 Medidas de Segurança para Proteger Seus Servidores. Para segurança digital pessoal, o vídeo da Eva Galperin é excelente: Especialista em Internet desmistifica cyber segurança.

Primeiros passos com o pandas

Mon, 30 Nov 2020 13:00:00 -0300

Obs.: Originalmente publicado no computando-arte dia 30Nov2020

O que é o pandas

Pandas é uma biblioteca Python para trabalhar com dados tabulares, que como o nome sugere são os dados estruturados na forma de uma tabela: ou seja os elementos são arranjados em colunas verticais e linhas (ou registros) horizontais, dessa forma cada elemento é formado pela intersecção de uma coluna e uma linha.

É uma das biblioteca mais importantes para Ciência de Dados. As principais bibliotecas são:

Aprendizado de máquina: scikit-learn
Vetores e matrizes: numpy
Scipy: várias coisas científicas(computação científica) 😜
Gráficos: matplotlib, seaborn, plotly
Redes neurais: pytorch e tensorflow

Sobre a linguagem Python

Python é umas das principais linguagens de programação usada em Ciência de Dados, é uma linguagem fácil de aprender e existem muitas bibliotecas excelentes disponíveis. Além de Python, a linguagem R também é muito utilizada.

Quer aprender Python? Recomendo o livro do Luciano Ramalho: Python Fluente. Quer uma palinha? Ele fez uma live: Luciano Ramalho – A Beleza de Python.
Não curte livro? O Fernando Masanori fez uma série de vídeos: python para zumbis.
Canais do youtube: Dunossauro (Eduardo Mendes) e o canal Programação dinâmica tem vários vídeos excelentes.
Já manja de programar e quer só aprender como faço determinada tarefa em Python: pythoncheatsheet.org
Praticar: tem um “jogo” que são dados alguns problemas para serem resolvidos em Python: py.checkio.org
Curte minecraft? Na Raspberry Pi é possível interagir em Python com o jogo: projects.raspberrypi.org/en/projects/getting-started-with-minecraft-pi.

Jupyter notebooks e como preparar seu ambiente

Quando estiver programando em Python ou outras linguagens interpretadas, uma opção popular é a utilização de Jupyter Notebooks. O Jupyter Notebook é uma espécie de “caderno com células” com código ou texto, que pode ser formatado com Markdown (inclusive com formulas LaTeX). Dessa forma, é possível escrever uma vez só o código que gera os gráficos, resultados, texto para um artigo, slides, e etc. Além de que as células são executadas de forma interativa, tornando-se mais fácil de programar dessa forma.

Dicas para os Jupyter notebooks:

Para usar o jupyter é simples, crie a célula e use shift+enter para executar aquela célula.
Precisa instalar um pacote? coloque um ! antes do comando que quer instalar, por exemplo: !pip install numpy
Coloque ? antes do que você quer procurar o manual, por exemplo a função split em strings: ?str.split. Então, será aberto um painel com o manual dessa função.
Como instalar tudo? O jeito mais simples é usar o anaconda.com que instala todo ambiente Python em sua máquina de maneira simples.
Outra opção é programar direto do navegador sem precisar instalar nada: o colab.research.google.com é uma opção popular, e ainda usufrui de GPUs para treinar redes neurais rapidamente e gratuito.
Pra quem curte software livre e não quer usar a plataforma do google o cocalc.com é uma ótima opção.

Começando pelo começo: séries de valores no pandas

Antes de tudo, vamos importar o pandas:

import pandas as pd

Vamos escrever uma série de valores. Podemos definir os índices da serie de valores, tornando a mais completa e fácil de entender e acessar.

gasto_semana = pd.Series([20,40,50,30,40,80,15])
gasto_semana.index = [“domingo”, “segunda”, “terca”, “quarta”, “quinta”, “sexta”, “sabado”]
gasto_semana

domingo    20
segunda    40
terca      50
quarta     30
quinta     40
sexta      80
sabado     15
dtype: int64

Para acessar os valores procedemos da mesma forma que com listas: gasto_semana[“segunda”]. Dessa forma, o valor a ser retornado será o valor da segunda-feira.

Também temos a flexibilidade de realizar cálculos, por exemplo elevar ao quadrado os gastos da semana ao quadrado:

gasto_semana**2

domingo     400
segunda    1600
terca      2500
quarta      900
quinta     1600
sexta      6400
sabado      225
dtype: int64

Uma vez que a série foi criada, podemos, por exemplo, calcular a mediana, as estatísticas descritivas (média, desvio padrão, quartis, e etc.) e contar os valores únicos da série:

gasto_semana.median()

40.0

gasto_semana.describe(percentiles = [.25, .5, .75])

count     7.000000
mean     39.285714
std      21.684974
min      15.000000
25%      25.000000
50%      40.000000
75%      45.000000
max      80.000000
dtype: float64

gasto_semana.value_counts(normalize=False)

40    2
15    1
30    1
20    1
80    1
50    1
dtype: int64

Podemos procurar por valores que satisfazem uma determinada condição:

gasto_semana > 30

domingo    False
segunda     True
terca       True
quarta     False
quinta      True
sexta       True
sabado     False
dtype: bool

Repare que a saída é uma série com os mesmos índices da serie original e com valores True ou False para os valores que satisfazem ou não a condição.

Um detalhe é que se quisermos procurar por valores que satisfazem diversas condições, temos que os usar operadores bitwise, por exemplo E (and) é representado por &, OU (or) por | e negação (NOT) por ~

(gasto_semana > 30) & (gasto_semana < 80)

domingo    False
segunda     True
terca       True
quarta     False
quinta      True
sexta      False
sabado     False
dtype: bool

Por fim, se usarmos isso dentro da série original, vamos gerar uma serie com os valores que satisfazem as condições:

gasto_semana[(gasto_semana > 30) & (gasto_semana < 80)]

segunda    40
terca      50
quinta     40
dtype: int64

Dataframes

Dataframe é um estrutura bidimensional de dados. Pense em dataframe como uma tabela ou matriz. No fundo, o dataframe tem algumas colunas onde cada coluna é uma série de dados e as colunas são “amarradas” pelos índices.

Vamos importar um dataframe de gorjetas, onde foram anotadas diversas informações de gorjetas como sexo, se é fumante ou não, dia da semana, quantas pessoas na mesa, e etc.

import seaborn as sns
tips_df = sns.load_dataset(“tips”)
tips_df.head(6) # exibe os 6 primeiros registros (use tail para ultimos)

Uma das primeiras coisas que eu gosto de fazer assim que importo os dados é utilizar a função info para vermos se o type de cada coluna foi identificado corretamente.

E também podemos ver quanto de memória é utilizada. Caso o conjunto de dados seja grande, é interessante tentar alguns “truques” como transformar alguma coluna como categórico para poupar memória 😜

tips_df.info()

<class 'pandas.core.frame.DataFrame'>
RangeIndex: 244 entries, 0 to 243
Data columns (total 7 columns):
 #   Column      Non-Null Count  Dtype   
---  ------      --------------  -----   
 0   total_bill  244 non-null    float64 
 1   tip         244 non-null    float64 
 2   sex         244 non-null    category
 3   smoker      244 non-null    category
 4   day         244 non-null    category
 5   time        244 non-null    category
 6   size        244 non-null    int64   
dtypes: category(4), float64(2), int64(1)
memory usage: 7.3 KB

Se quisermos saber qual o percentual de quem paga a gorjeta e é fumante, podemos utilizar o values_count conforme descrito na célula de código abaixo. Assim, saberemos que aproximadamente 60% dos pagantes de gorjeta fumam.

tips_df[‘smoker’].value_counts(normalize=True)

No     0.618852
Yes    0.381148
Name: smoker, dtype: float64

Podemos criar também colunas novas. Vamos calcular o total pago (total = valor_conta + valor_tip) e a porcentagem do valor da gorjeta com o total:

tips_df[‘total_payed’] = tips_df[“total_bill”] + tips_df[“tip”]
tips_df[‘tip_percentage’] = 100.0*tips_df[“tip”]/tips_df[“total_bill”]
tips_df.head()

Qual é a distribuição de percentagem da gorjeta? E do valor total?

Como podemos ver, em média as gorjetas representam 15% do valor da conta, o que corresponde a ao valor médio da gorjeta de 2.9 dólares.

Referente ao valor total, a média é de 20.6 dólares e mediana de 22.8 dólares.

Fumantes tendem a pagar mais gorjeta? Podemos agrupar os valores pela coluna smoker e fazer um describe

tips_df.groupby([‘smoker’]).tip_percentage.describe()

Aparentemente não faz muita diferença se o cliente é fumante ou não para pagar um percentual maior de gorjeta (mediana ficou 15.4% para fumantes e 15.6% para não fumantes).

E o dia da semana junto com o dia? Faz diferença? Podemos agrupar com mais de uma coluna

tips_df.groupby([‘day’, ‘time’]).tip_percentage.describe()

E gráficos? Fazer gráficos com o pandas é muito simples:

tips_df.plot.scatter(x=’total_bill’,y=’tip_percentage’)

Neste gráfico queremos ver se existe uma correlação entre o valor conta e o percentual de gorjeta concedido. Vemos que pelo contrario, uma leve correlação negativa: quanto maior o valor da conta menos será pago de gorjeta, percentualmente.

Outra opção é usar a biblioteca de gráficos seaborn, que além de ser fácil de usar, os gráficos ficam bem bonitos

import seaborn as sns
sns.scatterplot(data=tips_df, x=’total_bill’,y=’tip_percentage’, hue=’smoker’)

Ler e gravar os dados

Para ler dados com pandas é super simples. Por exemplo, para ler um csv basta fazer (inclusive funciona se passar o link do csv):

df = pd.read_csv('arquivo.csv')

É possível ler de arquivos excel com pd.read_excel, HDF5, SQL, inclusive Parquet — um formato muito usado em Big Data. Para salvar o arquivo basta fazer df.to_csv(‘arquivo.csc’), e etc.

Dicas legais

Raspagem web: o pandas consegue extrair tabelas de páginas web. Para isso, basta usar a função pd.read_html(<link_da_pagina>), assim como mágica o pandas lê a tabela como um dataframe.

Pivot tables: se você está acostumado a fazer pivot tables como no excel, o pandas faz facilmente através da função pd.pivot_table, conforme o exemplo abaixo:

pd.pivot_table(tips_df, index=’size’, columns=’smoker’, values=’tip_percentage’, aggfunc=’median’)

Fizemos uma pivot table onde as linhas são quantas pessoas tem à mesa, as colunas significam se o cliente é fumante ou não, e os valores são a porcentagem da gorjeta agregada com mediana.

Conclusão

Como vimos, o pandas é uma biblioteca muito fácil de usar e que faz mágica. Para aprender mais, existe o guia de usuário com o passo-a-passo e a documentação oficial. Outra referência legal e rapidinha são as dicas do Kevin Markham, ele montou uma lista com 100 dicas ótimas para usar pandas: dataschool.io/python-pandas-tips-and-tricks/.

Projeto novo: Divulgação cientifica no medium

Mon, 23 Nov 2020 14:00:00 -0300

Edits

21Abr2021: Agora também estamos no dev.to

Juntei com uns amigos e formamos um grupo de divulgação cientifica de estatística, matemática, ciência de dados e computação no medium.

A ideia é publicar um texto por semana.

Confira aqui: medium.com/computando-arte

e no dev.to: dev.to/computandoarte

Assine o feed RSS: medium.com/feed/computando-arte e dev.to/feed/computandoarte

Mandem sugestões, dicas e feedback :)