Posts on João Senger

Docker - Comandos Basicos

joaosenger.dev@gmail.com (João Senger) — Thu, 19 Mar 2026 12:10:33 -0300

Conheça os principais comandos do Docker que utilizamos praticamente todos os dias.

# Introdução

O Docker é a ferramenta mais utilizada para gerenciamento de containers atualmente. Uma das coisas que chamam a atenção ao começar a estudar Docker é que seus comandos seguem uma lógica, que se bem estudada facilita o entendimento de como gerenciar melhor nossos containers.

# Entendo o padrão

Praticamente todos os comandos do Docker seguem o mesmo padrão:

docker OBJETO AÇÃO [opções]

Onde:

Objeto é o que queremos gerenciar, por exemplo: imagens, redes, volumes, etc

Ação é o verbo, o que queremos fazer, por exemplo: ls, rm, run, inspect, start, stop, etc

Opções são auxiliares dos comandos, por exemplo, o comando docker container ls lista os containers em execução, porém, se adicionarmos a opção (ou flag) -a a saída do comando irá listar todos os containers, inclusive os que estão parados, exemplo: docker container ls -a.

# Comandos de containers

Containers são as instancias em execucao criadas a partir de uma imagem. No dia a dia, estes são os comandos mais usados:

# Lista containers em execucao
docker container ls

# Lista todos os containers (inclusive parados)
docker container ls -a

# Cria e inicia um container
docker container run -d --name meu-nginx -p 8080:80 nginx

# Para um container em execucao
docker container stop meu-nginx

# Inicia um container parado
docker container start meu-nginx

# Remove um container parado
docker container rm meu-nginx

# Mostra detalhes tecnicos de um container
docker container inspect meu-nginx

# Exibe logs do container
docker container logs meu-nginx

Atalhos equivalentes muito comuns:

docker ps        # equivale a docker container ls
docker rm <id>   # equivale a docker container rm <id>

# Comandos de imagens

Imagens são os “moldes” usados para criar containers. Também seguem o mesmo padrão:

# Lista imagens locais
docker image ls

# Baixa uma imagem do registry
docker image pull nginx:latest

# Constroi uma imagem a partir de um Dockerfile
docker image build -t minha-api:1.0 .

# Remove uma imagem
docker image rm nginx:latest

# Mostra histórico de camadas de uma imagem
docker image history nginx:latest

# Mostra detalhes técnicos da imagem
docker image inspect nginx:latest

Atalhos equivalentes:

docker images          # equivale a docker image ls
docker rmi <imagem>    # equivale a docker image rm <imagem>

# Comandos de volumes e redes

Volumes e redes sao recursos de apoio muito importantes para persistencia de dados e comunicacao entre containers.

# Volumes
docker volume ls
docker volume create dados-app
docker volume inspect dados-app
docker volume rm dados-app

# Redes
docker network ls
docker network create minha-rede
docker network inspect minha-rede
docker network rm minha-rede

# Comandos de limpeza

Com o tempo, sobram recursos não usados no ambiente. Estes comandos ajudam na manutenção:

# Remove containers parados
docker container prune

# Remove imagens sem uso
docker image prune

# Remove volumes nao utilizados
docker volume prune

# Remove redes nao utilizadas
docker network prune

# Limpeza geral (use com cuidado)
docker system prune -a

# Fluxo pratico no dia a dia

Um fluxo simples e comum:

Ver o que esta rodando: docker container ls
Ver recursos locais: docker image ls, docker volume ls, docker network ls
Subir um servico: docker container run ...
Validar logs e estado: docker container logs ... e docker container inspect ...
Encerrar e limpar quando necessario: docker container stop, docker container rm, docker * prune

# Conclusão

Quando você entende o padrão docker OBJETO ACAO [opcoes], aprender novos comandos fica muito mais fácil. Em vez de decorar tudo, você passa a raciocinar sobre o que deseja gerenciar e qual ação deseja executar.

Esse padrao vale para praticamente todo o ecossistema Docker e acelera muito o trabalho no dia a dia.

Docker - Container parando após fechar a sessão SSH

joaosenger.dev@gmail.com (João Senger) — Wed, 19 Mar 2025 13:20:56 -0300

Ao encerrar a sessão SSH com o servidor, seu container para? Entenda o que pode estar acontecendo.

# Introdução

## O Problema

Recentemente tive que subir um ambiente bem simples na AWS, era uma aplicação com dois containers que eram executados pelo Docker Compose. Porém, uma coisa estranha estava acontecendo: ao encerrar a sessão ssh com o servidor os containers imediatamente ficavam indisponíveis.

# Investigando o problema

## Docker Logs

Uma das primeiras coisas que eu faço para investigar uma parada inesperada de um container é analisar seus logs, isso pode ser facilmente analisado através do comando:

docker logs container_name

Ao analisar os logs, percebi o seguinte erro: [Tue Mar 18 19:13:05.229898 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00169: caught SIGTERM, shutting down

Ao bater o olho, percebi que a ação de me desconectar do servidor estava desligando os containers, através de um comando SIGTERM, que basicamente é um comando kill para parar um processo.

## Buscando uma solução

Ao pesquisar na internet sobre o problema eu descobri que usuários que executavam o Docker como usuários comuns e não como root enfrentavam esse problema, o que faz sentido. Quando um usuário faz logout todos os seus processos são encerrados, ou seja, ao fechar a conexão ssh todos os processos eram encerrados. Importante: eu estava usando o usuário ubuntu, que é criado pelo EC2 ao criar uma VM com AMI Ubuntu. Para resolver o problema eu precisaria fazer algo para que os processos não fossem encerrados, essa seria a minha solução.

# Aplicando a solução

## Linger

Basicamente, esse carinha faz com que os processos do usuário continuem em execução após o logout.

# Faz os processos continuarem em execução
sudo loginctl enable-linger $(whoami)

# Faz o Docker ser iniciado automaticamente para o usuário atual
systemctl --user enable docker

Após isso, pausei as aplicações com o comando docker-compose down e subi novamente com docker-compose up -d.

Após isso, problema resolvido. 😁

Entenda: GNU, Linux, FSF e GPL

joaosenger.dev@gmail.com (João Senger) — Tue, 11 Mar 2025 20:30:44 -0300

Entenda o que é o Projeto GNU, Linux, Free Software Foundation e a Licença GPL - GNU General Public License.

# GNU/Linux

## Breve história sobre o GNU

Na década de 1980, no MIT, um nerd chamado Richard Stallman estava descontente com o desenvolvimento de softwares exclusivamente proprietários, onde os desenvolvedores e usuários não tinham liberdade para estudar o software.

Em 1983 Stallman criou o Projeto GNU (Gnu is Not Unix) com a ideia de um Unix livre, sem as amarras que os softwares proprietários da época impunham, assim, ele e diversos programadores entusiastas da ideia de software livre começaram a desenvolver algumas das ferramentas que são utilizadas até hoje, como o compilador GCC, o Bash e muitos outros.

## O Surgimento do Linux

Enquanto o Projeto GNU avançava no desenvolvimento de um sistema operacional livre, faltava um componente essencial no sistema: um kernel livre. Kernel é o componente do sistema operacional responsável por “conversar” com o hardware, é a ponte que liga a parte “física” do computador com a “lógica”. O Projeto GNU estava desenvolvendo seu próprio kernel, chamado Hurd, porém, seu progresso de desenvolvimento era lento.

Em 1991 um estudante finlandês chamado Linus Torvalds começou a desenvolver seu próprio kernel como um hobby, seu objetivo era criar um sistema que fosse compatível com Unix, livre e que pudesse ser executado em computadores pessoais.

Torvalds postou sua ideia em um fórum da época e convidou outros programadores para contribuir com o projeto. Assim, o kernel foi chamado de Linux (uma mistura de Linus + Unix).

## GNU/Linux

A utilização das ferramentas do Projeto GNU com o kernel Linux resultou no hoje tão conhecido GNU/Linux. Essa fusão só foi possível graças às características do software livre.

# Free Software Foundation e GPL

## Free Software Foundation

A Free Software Foundation foi criada em 1985 por Richard Stallman com o objetivo de promover o software livre. A FSF trabalha para garantir que os programas possam ser usados, estudados, modificados e compartilhados livremente, sem restrições de empresas ou governos.

## Licença GPL - GNU General Public License

Também criada por Stallman, a A GNU Public License, GNU GPL ou somente GPL é uma licença de software idealizada para garantir quatro liberdades fundamentais aos usuários:

Liberdade para executar o programa
Liberdade para estudar e modificar o código-fonte
Liberdade para redistribuir cópias
Liberdade para distribuir versões modificadas

O casamento entre o GNU e o Linux se deve muito pelo motivo de ambos compartilharem a filosofia de software livre e às licenças GPL que estão presentes em ambos softwares.

# Conclusão

O GNU/Linux é o sistema operacional que domina o mercado tech. Está presente em servidores, smartphones, smartwatches, geladeiras inteligentes e até mesmo em Marte, a bordo da Ingenuity.

Sintetizando, GNU é um conjunto de ferramentas e utilitários projetados para criar um sistema operacional livre, baseado nos princípios Unix. Linux é um Kernel que dá vida às ferramentas GNU.

GNU + Linux = Sistema Operacional completo.

Django REST framework: API CRUD com Autenticação JWT

joaosenger.dev@gmail.com (João Senger) — Thu, 04 Jul 2024 21:46:06 -0300

Aprenda a criar uma API REST profissional utilizando Django REST framework. Construa um CRUD completo com autenticação de usuários utilizando JWT.

# Introdução

## O que iremos aprender?

Nosso projeto será criar uma API para gerenciar tarefas (To-Do). Utilizaremos usuários e permissões do Django para acessar os recursos da API, além de autenticação por JWT.

O código do projeto pode ser encontrado neste link.

Este artigo não é para desenvolvedores totalmente leigos, tópicos como o que é um token JWT, o que é uma API REST ou o que é o protocolo HTTP não serão abordados.

## O que é o Django REST framework?

Django REST framework é um kit de ferramentas para construir APIs Web dentro do ecossistema Django. Possui diversas implementações prontas, como Serializers, Views, autenticação e permissões.

## Quais os benefícios em se utilizar um Framework para o desenvolvimento?

Segurança: proteção contra vulnerabilidades comuns, como SQL Injection, Cross-Site Scripting (XSS) e Cross-Site Request Forgery (CSRF)
ORM (Object-Relational Mapping): facilitando o trabalho com bancos de dados relacionais, permitindo manipular o banco de dados usando objetos prontos ao invés de queries SQL
Comunidade: desenvolvimento colaborativo, diversos programadores testam a ferramenta e contribuem para a evolução do framework
Rapidez no desenvolvimento: funcionalidades prontas podem ser usadas para implementação rápida e segura de projetos
Manutenção: código limpo e organizado garantem facilidade na manutenção e implementação de novas features
Confiabilidade: frameworks populares (como o DRF - Django REST framework) são amplamente utilizados e testados, reduzindo a probabilidade de bugs e falhas.

# Pré-requisitos

## Conhecimentos:

Conhecimentos básicos sobre API REST
Conhecimento básico em desenvolvimento web
Python: conhecimentos básicos e orientação a objetos
Conhecimento básico sobre o protocolo HTTP

## Softwares:

Python 3.8 ou superior
Editor de código (recomendo o VSCode)
Postman ou Insomnia (opcional)

# Configuração inicial

Primeiro, vamos criar um ambiente virtual para o nosso projeto:

python -m venv venv
source venv/bin/activate # para usuários Linux/MacOS
.\venv\Scripts\Activate.ps1 # para usuários Windows

Com o ambiente criado, vamos instalar o Django e o Django Rest Framework (DRF):

pip install django && pip install djangorestframework

## Iniciando e configurando o projeto

Agora que temos nosso ambiente com o Django e o DRF instalados, vamos iniciar um novo projeto Django:

django-admin startproject app .

Podemos testar o nosso novo projeto rodando o comando:

python manage.py runserver

Ao acessar http://127.0.0.1:8000/ uma página de ‘welcome’ do Django deverá ser exibida:

Podemos parar o servidor pressionando CTRL+C.

## Criando o nosso primeiro aplicativo

Com o nosso projeto Django criado, podemos criar um novo aplicativo, que será chamado de todo_api:

python manage.py startapp todo_api

Importante: o nosso projeto se chama app e nesse projeto temos uma aplicação chamada todo_api, não confunda!

Um novo diretório chamado todo_api foi criado em nosso projeto. Precisamos inserir o Django REST framework e o nosso aplicativo nas configurações do nosso projeto app, para isso, acesse o arquivo app/settings.py e adicione a todo_api aos INSTALLED_APPS:

# app/settings.py

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',

    'todo_api',
]

Agora temos o nosso projeto e aplicativo configurados, podemos fazer a nossa primeira operação no banco de dados, que cria um banco SQLite e as tabelas iniciais do Django:

python manage.py migrate

# Desenvolvimento da API

Com o projeto e a aplicação criados e configurados, podemos iniciar o desenvolvimento da API de fato.

Começaremos o desenvolvimento do nosso Model, ou seja, o modelo da nossa API no banco de dados, que será simples.

## Models e Serializers

Nosso modelo terá apenas três campos: id, task e done, sendo:

id: criado automaticamente pelo Django, não precisamos declará-lo (que facilidade!)
task: será o nome da nossa “tarefa”, será um dado do tipo CharField
done: será o status da nossa tarefa, será um booleano (true/false)

Abra o arquivo todo_api/models.py e insira o seguinte código:

# todo_api/models.py
from django.db import models


class Todo(models.Model):
    task = models.CharField(max_length=250)
    done = models.BooleanField()

    def __str__(self):
        return self.task

O Django irá interpretar esse modelo e criará automaticamente a tabela no banco de dados conforme as nossas especificações, não precisamos nos preocupar com SQL, essa é uma das facilidades que o Django ORM nos traz.

Para que o Django “leia” os arquivos models do nosso projeto, precisamos rodar o comando:

python manage.py makemigrations

Após isso, rodamos o comando migrate para aplicar:

python manage.py migrate

Uma tabela será criada no seu banco de dados local (SQLite) com o nome todo_todo_api, ou seja: nomemodel_nomeapp. Os campos id, task e done também serão criados.

O nosso modelo foi criado, porém, os dados da API devem trafegar em formato JSON, e não no formato de objetos do banco de dados, para “serializar” os nossos dados de objeto para json, precisamos criar um serializer.

Como tudo no Django é simples, essa funcionalidade já está pronta, basta utilizá-la!

Crie um arquivo chamado serializers.py dentro da sua app todo_api: todo_api/serializers.py e inseira o código abaixo:

# todo_api/serializers.py
from rest_framework import serializers
from todo_api.models import Todo


class TodoSerializer(serializers.ModelSerializer):

    class Meta:
        model = Todo
        fields = '__all__'

Basicamente importamos o nosso Model Todo, que é a representação dos nosso dados no banco de dados e utilizamos o ModelSerializer do Django REST framework, que fará a serialização de forma automática. Também informamos que queremos serializar todos os campos com fields = __all__

## Views e View Classes

O arquivo todo_api/views.py é responsável pela regra de negócio da nossa API, aqui será implementa toda a lógica do nosso CRUD. Como a nossa API é simples, utilizaremos duas classes prontas do DRF para abstrair as operações, sendo elas:

ListCreateAPIView: responsável pelos verbos GET e POST, lista todas as tarefas e permite a criação de uma nova tarefa.
RetrieveUpdateDestroyAPIView: trabalha com os id’s das tarefas, aqui podemos utilizar todos os verbos http: GET, POST, PUT, DELETE. Podemos listar, alterar ou deletar as tarefas de acordo com o seu id único.

Dentro do arquivo todo_api/views.py insira o código:

# todo_api/views.py
from rest_framework import generics
from todo_api.models import Todo
from todo_api.serializers import TodoSerializer


class TodoCreateListView(generics.ListCreateAPIView):
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer


class TodoRetrieveUpdateDestroyView(generics.RetrieveUpdateDestroyAPIView):
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer

Criamos duas classes, uma para cada View Class do DRF, agora, podemos configurar nossas URLs para enviar as requisições para as nossas views.

# URLs e Versionamento da API

Dentro do diretório todo_api crie um arquivo chamado urls.py e insira o código abaixo:

# todo_api/urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('todos/', views.TodoCreateListView.as_view(), name='todo-create-list-view'),
    path('todos/<int:pk>', views.TodoRetrieveUpdateDestroyView.as_view(), name='todo-detail-view'),
]

Esse trecho de código informa que ao acessar a nossa api na rota /todos/ e /todos/id/ o Django deve utilizar a view configurada anteriormente.

Não é uma boa prática acessar diretamente as rotas, a boa prática é utilizar o versionamento de urls, ou seja, antes de acessar o caminho /todos/, por exemplo, acessamos /api/v1/todos/

Isso garante que em uma nova implementação, no caso uma v2, os clientes que utilizam o endpoint /v1/ não sejam afetados.

Para implementar o versionamento, acesse o arquivo app/urls.py e inseira o código:

# app/urls.py
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/v1/', include('todo_api.urls')),
]

Utilizamos o include do Django para criar um versionamento, agora, nossa api será acessada por: http://127.0.0.1:8000/api/v1/todos/

## API funcionando, primeiro teste!

Nossa API já está funcional, podemos testá-la.

python manage.py runserver

Acesse http://127.0.0.1:8000/api/v1/todos/ e crie algumas tarefas.

Ao acessar a url passando algum id, podemos ver a RetrieveUpdateDestroyAPIView em ação, com as opções de visualizar, alterar ou deletar um recurso específico.

## Django ADMIN - Criação e gerenciamento de usuários

O Django já nos traz pronta uma plataforma para gerenciar usuários, grupos de usuários e Models do banco de dados.

Para criar o primeiro usuário (root) digite no terminal:

python manage.py createsuperuser

Para adicionarmos nosso model no Django Admin, acesse o arquivo todo_api/admin e insira o código:

# todo_api/admin.py
from django.contrib import admin
from todo_api.models import Todo


@admin.register(Todo)
class TodoAdmin(admin.ModelAdmin):
    list_display = ('id', 'task', 'done')

Execute o servidor:

python manage.py runserver

Acesse a url do django admin: http://127.0.0.1:8000/admin/

Insira as suas credenciais e acesse a dashboard.

Crie pelo menos um usuário, sem credenciais de admin para prosseguirmos.

## Segurança - Autenticação com JWT e proteção dos endpoints

Com o nosso CRUD pronto e com o django admin fazendo o gerenciamento de usuários, podemos começar a autenticação da nossa API.

Iremos exigir que apenas usuários autenticados tenham acesso à API, além de protegeremos os nossos endpoints, onde apenas usuários autenticados e com permissões poderão acessar a API e executar ações.

Instale o Django REST framework Simple JWT

pip install djangorestframework-simplejwt

Na configuração do projeto, app/settings.py adicione o código abaixo no final do arquivo:

# app/settings.py
REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    )
}

SIMPLE_JWT = {
    "ACCESS_TOKEN_LIFETIME": timedelta(days=1),
    "REFRESH_TOKEN_LIFETIME": timedelta(days=7),
}

No começo do arquivo, importe o timedelta:

from datetime import timedelta

Nesse código configuramos que a autenticação será feita pelo Simple JWT e qual será o tempo de vida do Token antes dele expirar.

Criando o endpoint para gerar o token

Precisamos criar um endpoint para gerar o nosso token jwt. Criaremos um novo aplicativo para ser responsável pela autenticação:

python manage.py startapp authentication

Adicione o novo app no arquivo app/settings.py:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'rest_framework',
    'todo',
    'authentication',
]

Dentro dessa nova app, crie um arquivo chamado urls.py e insira o código:

# authentication/urls.py
from django.urls import path
from rest_framework_simplejwt.views import TokenObtainPairView, TokenRefreshView, TokenVerifyView

urlpatterns = [
    path('authentication/token/', TokenObtainPairView.as_view(), name='token-obtain-pair-view'),
    path('authentication/token/refresh/', TokenRefreshView.as_view(), name='token-refresh-vier'),
    path('authentication/token/verify', TokenVerifyView.as_view(), name='token-verify-view')
]

Estamos criando endpoints para gerar o nosso token JWT, seu refresh e verify.

Tudo isso é abstraido pelo DRF, não precisamos criar tudo na mão.

Agora, no arquivo app/urls.py vamos importar nossos novos endpoints, o código deverá ficar assim:

# app/urls.py
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/v1/', include('authentication.urls')), # endpoint para autenticação
    path('api/v1/', include('todo_api.urls')),
]

Agora, vamos proteger nossas views. No arquivo todo/views.py vamos adicionar permission_classes em nossas rotas, esse é um recurso do DRF utilizado para proteger as rotas. O arquivo deverá ficar assim:

# todo/views.py
from rest_framework import generics
from rest_framework.permissions import IsAuthenticated
from todo_api.models import Todo
from todo_api.serializers import TodoSerializer


class TodoCreateListView(generics.ListCreateAPIView):
    permission_classes = (IsAuthenticated, )
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer


class TodoRetrieveUpdateDestroyView(generics.RetrieveUpdateDestroyAPIView):
    permission_classes = (IsAuthenticated, )
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer

Agora, ao tentar acessar algum recurso da nossa API, não será possível. Veja:

Para acessar, será necessário gerar um Token JWT na rota api/v1/authentication/token/.

A partir daqui, utilizaremos o Postman para fazer requisições à API, pois teremos que informar o token em nossas requisições.

Acesse o Postman e faça uma requisição POST na url 127.0.0.1:8000/api/v1/authentication/token/ passando o username/password no corpo da requisição body:

{
  "username": "yourusername",
  "password": "yourpassword"
}

Ao fazer a requisição informando o usuário e senha que você criou no Django Admin, será retornado um Access Token e um Verify Token, porém, nesse tutorial utilizaremos apenas o access token:

Copie o access token e faça uma nova requisição na rota 127.0.0.1:8000/api/v1/todos passando o token copiado em Authorization > Bearer Token, conforme imagem abaixo:

Com isso, apenas usuários autenticados podem acessar nossas tarefas. Mas, e se eu quiser que algum usuário tenha permissão apenas de leitura, mas não de alteração dos dados? ou seja, pode fazer um GET, mas não um PUT? Para resolver esse problema, utilizaremos as permissões de usuários.

## Permissões de Usuários

Nesse ponto apenas usuários autenticados podem utilizar a API, porém, queremos restringir o acessos desses usuários. Por exemplo, determinado usuário pode ter apenas permissão de leitura GET, enquanto outro usuário pode ler e criar novas tarefas GET e POST, enquanto outro tipo de usuário pode fazer todas as ações. Para isso, utilizaremos as permissões de usuários do Django.

Vamos criar dois exemplos, o primeiro será um grupo de usuários que apenas pode fazer GET e o segundo com todas as permissões.

Acesse o Django Admin
Clique em “Groups”
Crie um grupo chamado "read_only" e dê a permissão Todo_Api | todo | Can view todo
Salve
Repita o processo, agora crie um crupo chamado "full_access" e dê as permissões: Todo_Api | todo | Can view todo
Todo_Api | todo | Can add todo
Todo_Api | todo | Can delete todo
Todo_Api | todo | Can change todo

Exemplo de criação do grupo “full_access”:

Agora temos dois grupos de usuários com permissões distintas, essa é a melhor prática para gerenciamento de permissões de usuários.

Agora, precisamos informar no código que os usuários além de estarem autenticados devem ter permissão para executar as ações na API.

Dentro de app crie um arquivo chamado permissions.py e insira o código abaixo:

# app/permissions.py
from rest_framework import permissions


class GlobalDefaultPermission(permissions.BasePermission):

    def has_permission(self, request, view):
        model_permission_codename = self.__get_model_permission_codename(
            method=request.method,
            view=view,
        )

        if not model_permission_codename:
            return False

        return request.user.has_perm(model_permission_codename)

    def __get_model_permission_codename(self, method, view):
        try:
            model_name = view.queryset.model._meta.model_name
            app_label = view.queryset.model._meta.app_label
            action = self.__get_action_sufix(method)
            return f'{app_label}.{action}_{model_name}'
        except AttributeError:
            return None

    def __get_action_sufix(self, method):
        method_actions = {
            'GET': 'view',
            'POST': 'add',
            'PUT': 'change',
            'PATCH': 'change',
            'DELETE': 'delete',
            'OPTIONS': 'view',
            'HEAD': 'view',
        }
        return method_actions.get(method, '')

Esse código sobrescreve a função has_permission herdada de permissions.BasePermission. Essa função deve retornar true ou false. O código verifica se o usuário tem permissão atrelada e retorna true ou false.

Por fim, vamos adicionar essa classe de permissões em nosso arquivo de views. No arquivo todo_api/views.py importe a classe GlobalDefaultPermission criada anteriormente e a inclua nas permission_classes. O código deverá ficar assim:

# todo_api/views.py
from rest_framework import generics
from rest_framework.permissions import IsAuthenticated
from todo_api.models import Todo
from todo_api.serializers import TodoSerializer
from app.permissions import GlobalDefaultPermission


class TodoCreateListView(generics.ListCreateAPIView):
    permission_classes = (IsAuthenticated, GlobalDefaultPermission)
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer


class TodoRetrieveUpdateDestroyView(generics.RetrieveUpdateDestroyAPIView):
    permission_classes = (IsAuthenticated, GlobalDefaultPermission)
    queryset = Todo.objects.all()
    serializer_class = TodoSerializer

# Testes

No Django Admin, crie um usuário e insira ele no grupo read_only, ele funcionará normalmente, depois, tente cadastrar uma nova tarefa, você não terá permissão. Após isso, adicione o grupo full_access no usuário e tente novamente, você conseguirá criar a tarefa.

Exemplo de tentativa de acesso com um usuário sem permissão:

Agora com o usuário fazendo parte do grupo read_only:

Assim, nossa API está completa. Fazemos operações de CRUD com usuários autenticados e rotas protegidas.

# Conclusão

Neste artigo aprendemos a utilizar o Django REST framework para criar uma API REST de forma simples, segura e profissional. O trabalho de um desenvolvedor Backend está muitas vezes atrelado a operações de CRUD no banco de dados, além de modelagem de dados e segurança da aplicação. Esta API não visa esgotar todas as melhores práticas de desenvolvimento, mas orientar desenvolvedores iniciantes sobre práticas utilizadas no mercado.

# Próximos passos

Sempre podemos melhorar o nosso projeto, no futuro iremos implementar algumas funcionalidades, como:

Configuração do linter Flake8 para padronização do código conforme a PEP 8
Criar a documentação da API com Swagger
Criar um Dockerfile para rodar a aplicação como um container
Fazer o Deploy da API na AWS com uma Pipeline completa (CodeCommit + CodePipeline + CodeBuild + ECR + ECS com Fargate)

Esses conteúdos serão publicados em breve aqui no blog.

Aguardo vocês. 😁

O que é Linux e o que são distribuições Linux

joaosenger.dev@gmail.com (João Senger) — Tue, 11 Jun 2024 07:36:03 -0300

Entenda o que é Linux e o que são distribuições Linux de forma resumida e sucinta.

# O que é Linux?

Linux é um Kernel, criado em 1991 por Linus Torvalds.

Kernel é o componente do sistema operacional responsável por “conversar” com o hardware, é a ponte que liga a parte “física” do computador com a “lógica”.

# Distribuições Linux

O Kernel é apenas uma parte de uma distribuição Linux, responsável pela comunicação do hardware com a camada de aplicações do sistema operacional. Por outro lado, uma distribuição Linux é a utilização do Kernel Linux com outras ferramentas, a fim de criar um sistema operacional usável, com interface, aplicativos, ferramentas administrativas e diversas outras funcionalidades.

Alguns exemplos de distribuições Linux:

Debian
RedHat
openSUSE
Slackware

# Finalizando

Linux é o kernel, o núcleo do sistema. Ele faz a comunicação do hardware (CPU, Memória e Dispositivos) com a parte lógica do sistema (aplicações).

Já uma Distribuição Linux é uma coleção de softwares que usam o Kernel Linux, dando vida a um sistema operacional usável baseado no Kernel Linux.

Vale a pena ressaltar que essa postagem não visa esgotar o entendimento do que é Linux e Distribuições Linux, é apenas uma visão geral de um tema muito amplo e discutido na comunidade.

# Quer saber mais sobre o tema?

RedHat: conheça o Linux
LPI: A evolução do Linux e sistemas operacionais populares
GuiaFoca Linux - Iniciante

Como hospedar um site estático utilizando o Amazon S3

joaosenger.dev@gmail.com (João Senger) — Tue, 11 Jun 2024 07:02:25 -0300

Aprenda a hospedar um site estático de forma simples utilizando o Amazon S3 da AWS.

# Antes de mais nada, o que é o Amazon S3?

O Amazon Simple Storage Service (S3) é o serviço de armazenamento de objetos da AWS que também pode ser utilizado para hospedagem de sites estáticos, ou seja, você não precisa subir o seu site em uma máquina virtual, instalar um Web Server como o Apache ou o NGINX, o Amazon S3 se encarrega de colocar o site no ar, você apenas deve fazer as configurações corretas, que veremos abaixo.

# Crie uma Conta na Amazon Web Services (AWS)

Se você ainda não possui uma conta na AWS, você precisará criar uma. Acesse aws.amazon.com e siga as instruções para se registrar. Você precisará fornecer informações de pagamento, mas fique tranquilo, ao criar a sua conta você ganha 12 meses de free-tier em alguns serviços, incluindo o S3, e os limites para uso do S3 são generosos.

“Free-tier? 12 meses gratuito?!”
Sim, o serviço Amazon S3 pode ser testado por 12 meses com limites interessantes para que possamos testar o serviço, para saber mais acesse a página do Nível gratuito da AWS

# Crie um Bucket no Amazon S3

Uma “bucket” é um recipiente de armazenamento no Amazon S3. Ele será usado para armazenar os arquivos do seu site. Siga estas etapas:

Faça login no Console de Gerenciamento da AWS.
No console, pesquise pelo nome “S3” e clique no serviço.
Clique em “Criar bucket”.
Escolha um nome exclusivo para o seu bucket e selecione uma região.
Deixe as configurações padrão e clique em “Create bucket”.

É indicado selecionar a região mais próxima ao seu público, no caso de nós brasileiros é a sa-east-1, que embora seja levemente mais cara em comparação às outras regiões da AWS, possui menor latência.

# Configurar as ‘Opções de Acesso’

Para que o seu site seja acessível publicamente, você precisará configurar as permissões corretas no bucket. Siga estas etapas:

No console do Amazon S3, selecione o bucket do seu site.
Clique em “Permissões” e em “Bloquear acesso público (configurações do bucket)” clique em “Editar”.
Desmarque a opção “Bloquear todo o acesso público” e clique em “Salvar alterações”. Confirme as alterações digitando “confirmar” e salve.
Ainda em “Permissões”, vá em “Política do bucket” clique em “Editar”.
Cole a política de bucket abaixo, substituindo <seubucket> pelo nome do seu bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::<seubucket>/*"
    }
  ]
}

Clique em “Salvar alterações”.

# Configurar a Bucket para Hospedagem de Site Estático

Clique em “Propriedades” e desça a página até “Hospedagem de site estático” e clique em “Editar”.
Selecione “Ativar” e em “Documento de índice” coloque o arquivo inicial do seu site, geralmente index.html.
Clique em “Salvar alterações”.

# Enviando os arquivos do site

Agora que tudo está configurado, você pode enviar os arquivos do seu site, para isso, siga os passo abaixo.

Clique em “Objetos” e em seguida “Carregar”
Arraste os arquivos do seu site ou clique em “Adicionar arquivos”, em seguida clique em “Carregar”.
Aguarde o carregamento dos arquivos.

# Acessando o seu site

Com a bucket configurada e com os arquivos do seu site, vamos descobrir a URL gerada e acessar o site.

Clique em “Propriedades” e desça a página até “Hospedagem de site estático”, a sua url aparecerá logo abaixo.
Agora, basta acessar e ver o seu site no ar. 🚀

# É possível utilizar o meu domínio com esse tipo de hospedagem?

Sim, é possível! Caso você registre o domínio pela própria AWS usando o Route53, fica ainda mais fácil, acesse este link para saber mais.

Modelos de Serviços em Computação em Nuvem

joaosenger.dev@gmail.com (João Senger) — Sun, 09 Jun 2024 23:17:30 -0300

Esse artigo visa esclarecer de forma simples os modelos de serviços em computação em nuvem e como eles são implementados em diferentes tipos de negócios.

# Modelos de Serviços em Computação em Nuvem

Os serviços de computação em nuvem são divididos em três modelos: Infraestrutura como Serviço (IaaS), Plataforma como Serviço (PaaS) e Software como Serviço (SaaS), sendo a IaaS o mais “baixo nível” e o SaaS de mais “alto nível”.

# Infraestrutura como Serviço (IaaS)

É o fornecimento de recursos computacionais sob medida para a sua aplicação. Você não precisa comprar um servidor de milhares de reais para rodar a sua aplicação, com um serviço de IaaS você pode comprar um servidor virtual e utilizá-lo sob medida para rodar a sua aplicação.

# Plataforma como Serviço (PaaS)

Com a Infraestrutura como Serviço já resolvemos a questão de não ter que gastar milhares de reais com um servidor, porém, configurá-lo e gerenciá-lo não é nada simples. A Plataforma como Serviço surge para resolver essa questão, agora toda a parte de gerenciamento da infraestrutura é realizado pela provedora de computação em nuvem. Esse modelo é ideal para quem quer focar no desenvolvimento da aplicação, abstraindo toda a parte de gerenciamento da infraestrutura.

# Software como Serviço (SaaS)

É a utilização de um software já pronto, aqui não nos preocupamos com a infraestrutura nem com o desenvolvimento da aplicação, utilizamos o software como um serviço. Um bom exemplo de SaaS é o Gmail, onde não precisamos nos preocupar com a infraestrutura, apenas utilizamos a solução já pronta.

# Analogia com um churrasco

Sim, esta é uma bela forma de entender os modelos de Cloud Computing, se liga:

No modelo de IaaS, o churrasco seria feito na churrasqueira do condomínio, afinal, você utilizaria a infraestrutura do local como um serviço. Porém, você ainda precisa se preocupar com a carne, o carvão, o tempero, as bebidas e tudo mais!

Já no modelo de PaaS, pense que você comprou um kit churrasco, agora além de utilizar a Infraestrutura, você não precisa se preocupar com a carne, o carvão, o tempero, as bebidas, tudo veio no kit! Mas… você ainda tem que assar e servir a carne.

Por fim, no modelo de SaaS, você não precisa se preocupar com nada. É como ir a uma churrascaria, onde a carne é simplesmente servida.

# Quer saber mais sobre o tema?

Confira os links abaixo:

AWS: Tipos de computação em nuvem
Redhat: IaaS x PaaS x SaaS