Posts on João Senger

Docker - Basic Commands

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

Learn the main Docker commands we use practically every day.

# Introduction

Docker is currently the most widely used tool for container management. One thing that stands out when you start learning Docker is that its commands follow a logical pattern, and understanding that pattern makes container management much easier.

# Understanding the pattern

Almost all Docker commands follow the same pattern:

docker OBJECT ACTION [options]

Where:

Object is what we want to manage, for example: images, networks, volumes, and so on.

Action is the verb, what we want to do, for example: ls, rm, run, inspect, start, stop, etc.

Options are command helpers. For example, the command docker container ls lists running containers, but if we add the option (or flag) -a, the output will list all containers, including those that are stopped, like this: docker container ls -a.

# Container commands

Containers are running instances created from an image. In daily work, these are the most commonly used commands:

# List running containers
docker container ls

# List all containers (including stopped ones)
docker container ls -a

# Create and start a container
docker container run -d --name my-nginx -p 8080:80 nginx

# Stop a running container
docker container stop my-nginx

# Start a stopped container
docker container start my-nginx

# Remove a stopped container
docker container rm my-nginx

# Show technical details about a container
docker container inspect my-nginx

# Show container logs
docker container logs my-nginx

Very common equivalent shortcuts:

docker ps        # equivalent to docker container ls
docker rm <id>   # equivalent to docker container rm <id>

# Image commands

Images are the “templates” used to create containers. They follow the same pattern as well:

# List local images
docker image ls

# Pull an image from a registry
docker image pull nginx:latest

# Build an image from a Dockerfile
docker image build -t my-api:1.0 .

# Remove an image
docker image rm nginx:latest

# Show image layer history
docker image history nginx:latest

# Show technical details about an image
docker image inspect nginx:latest

Equivalent shortcuts:

docker images          # equivalent to docker image ls
docker rmi <image>     # equivalent to docker image rm <image>

# Volume and network commands

Volumes and networks are very important support resources for data persistence and communication between containers.

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

# Networks
docker network ls
docker network create my-network
docker network inspect my-network
docker network rm my-network

# Cleanup commands

Over time, unused resources accumulate in your environment. These commands help with maintenance:

# Remove stopped containers
docker container prune

# Remove unused images
docker image prune

# Remove unused volumes
docker volume prune

# Remove unused networks
docker network prune

# General cleanup (use with care)
docker system prune -a

# Practical daily workflow

A simple and common workflow:

Check what is running: docker container ls
Check local resources: docker image ls, docker volume ls, docker network ls
Start a service: docker container run ...
Validate logs and state: docker container logs ... and docker container inspect ...
Stop and clean up when needed: docker container stop, docker container rm, docker * prune

# Conclusion

Once you understand the docker OBJECT ACTION [options] pattern, learning new commands becomes much easier. Instead of memorizing everything, you start reasoning about what you want to manage and which action you want to perform.

This pattern applies to almost the entire Docker ecosystem and speeds up day-to-day work.

Docker - Container stopping after closing SSH session

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

Does your container stop when you end the SSH session with the server? Understand what might be happening.

# Introduction

## The Problem

Recently I had to deploy a very simple environment on AWS, it was an application with two containers that were run by Docker Compose. However, something strange was happening: when I ended the ssh session with the server, the containers immediately became unavailable.

# Investigating the problem

## Docker Logs

One of the first things I do to investigate an unexpected container stop is to analyze its logs, this can be easily analyzed through the command:

docker logs container_name

When analyzing the logs, I noticed the following error: [Tue Mar 18 19:13:05.229898 2025] [mpm_prefork:notice] [pid 1:tid 1] AH00169: caught SIGTERM, shutting down

At first glance, I realized that the action of disconnecting from the server was shutting down the containers, through a SIGTERM command, which is basically a kill command to stop a process.

## Looking for a solution

When searching the internet about the problem, I discovered that users who ran Docker as regular users and not as root faced this problem, which makes sense. When a user logs out, all their processes are terminated, meaning when closing the ssh connection all processes were terminated. Important: I was using the ubuntu user, which is created by EC2 when creating a VM with Ubuntu AMI. To solve the problem I would need to do something so that the processes wouldn’t be terminated, this would be my solution.

# Applying the solution

## Linger

Basically, this little guy makes the user’s processes continue running after logout.

# Makes processes continue running
sudo loginctl enable-linger $(whoami)

# Makes Docker start automatically for the current user
systemctl --user enable docker

After that, I paused the applications with the docker-compose down command and brought them up again with docker-compose up -d.

After that, problem solved. 😁

Understanding: GNU, Linux, FSF and GPL

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

Understand what the GNU Project, Linux, Free Software Foundation and the GPL - GNU General Public License are.

# GNU/Linux

## Brief history about GNU

In the 1980s, at MIT, a nerd named Richard Stallman was dissatisfied with the development of exclusively proprietary software, where developers and users had no freedom to study the software.

In 1983 Stallman created the GNU Project (Gnu is Not Unix) with the idea of a free Unix, without the restrictions that proprietary software of the time imposed. Thus, he and several programmers enthusiastic about the idea of free software began to develop some of the tools that are used to this day, such as the GCC compiler, Bash and many others.

## The Birth of Linux

While the GNU Project advanced in developing a free operating system, an essential component was missing from the system: a free kernel. The kernel is the operating system component responsible for “talking” to the hardware, it’s the bridge that connects the “physical” part of the computer with the “logical” part. The GNU Project was developing its own kernel, called Hurd, however, its development progress was slow.

In 1991 a Finnish student named Linus Torvalds began developing his own kernel as a hobby, his goal was to create a system that was Unix-compatible, free and that could run on personal computers.

Torvalds posted his idea on a forum at the time and invited other programmers to contribute to the project. Thus, the kernel was called Linux (a mix of Linus + Unix).

## GNU/Linux

The use of GNU Project tools with the Linux kernel resulted in what is now so well known as GNU/Linux. This fusion was only possible thanks to the characteristics of free software.

# Free Software Foundation and GPL

## Free Software Foundation

The Free Software Foundation was created in 1985 by Richard Stallman with the goal of promoting free software. The FSF works to ensure that programs can be used, studied, modified and shared freely, without restrictions from companies or governments.

## GPL License - GNU General Public License

Also created by Stallman, the GNU Public License, GNU GPL or simply GPL is a software license designed to guarantee four fundamental freedoms to users:

Freedom to run the program
Freedom to study and modify the source code
Freedom to redistribute copies
Freedom to distribute modified versions

The marriage between GNU and Linux is largely due to the fact that both share the philosophy of free software and the GPL licenses that are present in both software.

# Conclusion

GNU/Linux is the operating system that dominates the tech market. It’s present in servers, smartphones, smartwatches, smart refrigerators and even on Mars, aboard Ingenuity.

In summary, GNU is a set of tools and utilities designed to create a free operating system, based on Unix principles. Linux is a kernel that brings the GNU tools to life.

GNU + Linux = Complete operating system.

Django REST framework: CRUD API with JWT Authentication

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

Learn how to create a professional REST API using Django REST framework. Build a complete CRUD with user authentication using JWT.

# Introduction

## What will we learn?

Our project will be to create an API for managing tasks (To-Do). We’ll use Django users and permissions to access API resources, plus JWT authentication.

The project code can be found at this link.

This article is not for complete beginners, topics like what is a JWT token, what is a REST API or what is the HTTP protocol will not be covered.

## What is Django REST framework?

Django REST framework is a toolkit for building Web APIs within the Django ecosystem. It has several ready-made implementations, such as Serializers, Views, authentication and permissions.

## What are the benefits of using a Framework for development?

Security: protection against common vulnerabilities, such as SQL Injection, Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)
ORM (Object-Relational Mapping): facilitating work with relational databases, allowing you to manipulate the database using ready-made objects instead of SQL queries
Community: collaborative development, several programmers test the tool and contribute to the framework’s evolution
Development speed: ready-made functionalities can be used for quick and secure project implementation
Maintenance: clean and organized code ensures ease in maintenance and implementation of new features
Reliability: popular frameworks (like DRF - Django REST framework) are widely used and tested, reducing the probability of bugs and failures.

# Prerequisites

## Knowledge:

Basic knowledge about REST API
Basic knowledge in web development
Python: basic knowledge and object orientation
Basic knowledge about HTTP protocol

## Software:

Python 3.8 or higher
Code editor (I recommend VSCode)
Postman or Insomnia (optional)

# Initial setup

First, let’s create a virtual environment for our project:

python -m venv venv
source venv/bin/activate # for Linux/MacOS users
.\venv\Scripts\Activate.ps1 # for Windows users

With the environment created, let’s install Django and Django Rest Framework (DRF):

pip install django && pip install djangorestframework

## Starting and configuring the project

Now that we have our environment with Django and DRF installed, let’s start a new Django project:

django-admin startproject app .

We can test our new project by running the command:

python manage.py runserver

When accessing http://127.0.0.1:8000/ a Django ‘welcome’ page should be displayed:

We can stop the server by pressing CTRL+C.

## Creating our first application

With our Django project created, we can create a new application, which will be called todo_api:

python manage.py startapp todo_api

Important: our project is called app and in this project we have an application called todo_api, don’t confuse them!

A new directory called todo_api was created in our project. We need to add Django REST framework and our application to our project app settings, for this, access the file app/settings.py and add todo_api to 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',
]

Now we have our project and application configured, we can make our first database operation, which creates an SQLite database and Django’s initial tables:

python manage.py migrate

# API Development

With the project and application created and configured, we can start developing the API itself.

We’ll start developing our Model, that is, the model of our API in the database, which will be simple.

## Models and Serializers

Our model will have only three fields: id, task and done, being:

id: automatically created by Django, we don’t need to declare it (how convenient!)
task: will be the name of our “task”, will be a CharField type data
done: will be the status of our task, will be a boolean (true/false)

Open the file todo_api/models.py and insert the following code:

# 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

Django will interpret this model and automatically create the table in the database according to our specifications, we don’t need to worry about SQL, this is one of the facilities that Django ORM brings us.

For Django to “read” the models files of our project, we need to run the command:

python manage.py makemigrations

After that, we run the migrate command to apply:

python manage.py migrate

A table will be created in your local database (SQLite) with the name todo_todo_api, that is: modelname_appname. The id, task and done fields will also be created.

Our model was created, however, API data must travel in JSON format, not in database object format, to “serialize” our data from object to json, we need to create a serializer.

As everything in Django is simple, this functionality is already ready, just use it!

Create a file called serializers.py inside your todo_api app: todo_api/serializers.py and insert the code below:

# 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__'

Basically we import our Todo Model, which is the representation of our data in the database and use Django REST framework’s ModelSerializer, which will serialize automatically. We also inform that we want to serialize all fields with fields = __all__

## Views and View Classes

The todo_api/views.py file is responsible for our API’s business logic, here all the logic of our CRUD will be implemented. As our API is simple, we’ll use two ready-made DRF classes to abstract operations, being:

ListCreateAPIView: responsible for GET and POST verbs, lists all tasks and allows creating a new task.
RetrieveUpdateDestroyAPIView: works with task ids, here we can use all http verbs: GET, POST, PUT, DELETE. We can list, change or delete tasks according to their unique id.

Inside the file todo_api/views.py insert the code:

# 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

We created two classes, one for each DRF View Class, now, we can configure our URLs to send requests to our views.

# URLs and API Versioning

Inside the todo_api directory create a file called urls.py and insert the code below:

# 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'),
]

This piece of code informs that when accessing our api on the route /todos/ and /todos/id/ Django should use the view configured previously.

It’s not a good practice to access routes directly, the good practice is to use url versioning, that is, before accessing the path /todos/, for example, we access /api/v1/todos/

This ensures that in a new implementation, in case of a v2, clients using the /v1/ endpoint are not affected.

To implement versioning, access the file app/urls.py and insert the code:

# 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')),
]

We use Django’s include to create versioning, now, our api will be accessed by: http://127.0.0.1:8000/api/v1/todos/

## API working, first test!

Our API is already functional, we can test it.

python manage.py runserver

Access http://127.0.0.1:8000/api/v1/todos/ and create some tasks.

When accessing the url passing some id, we can see the RetrieveUpdateDestroyAPIView in action, with options to view, change or delete a specific resource.

## Django ADMIN - User creation and management

Django already brings us a ready platform to manage users, user groups and database Models.

To create the first user (root) type in the terminal:

python manage.py createsuperuser

To add our model to Django Admin, access the file todo_api/admin and insert the code:

# 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')

Run the server:

python manage.py runserver

Access the django admin url: http://127.0.0.1:8000/admin/

Enter your credentials and access the dashboard.

Create at least one user, without admin credentials for us to proceed.

## Security - JWT Authentication and endpoint protection

With our CRUD ready and django admin managing users, we can start our API authentication.

We’ll require that only authenticated users have access to the API, plus we’ll protect our endpoints, where only authenticated and permitted users can access the API and execute actions.

Install Django REST framework Simple JWT

pip install djangorestframework-simplejwt

In the project configuration, app/settings.py add the code below at the end of the file:

# 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),
}

At the beginning of the file, import timedelta:

from datetime import timedelta

In this code we configure that authentication will be done by Simple JWT and what will be the token lifetime before it expires.

Creating the endpoint to generate the token

We need to create an endpoint to generate our jwt token. We’ll create a new application to be responsible for authentication:

python manage.py startapp authentication

Add the new app in the file 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',
]

Inside this new app, create a file called urls.py and insert the code:

# 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')
]

We’re creating endpoints to generate our JWT token, its refresh and verify.

All this is abstracted by DRF, we don’t need to create everything by hand.

Now, in the file app/urls.py we’ll import our new endpoints, the code should look like this:

# 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 for authentication
    path('api/v1/', include('todo_api.urls')),
]

Now, let’s protect our views. In the file todo/views.py we’ll add permission_classes to our routes, this is a DRF resource used to protect routes. The file should look like this:

# 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

Now, when trying to access any resource from our API, it won’t be possible. See:

To access, it will be necessary to generate a JWT Token on the route api/v1/authentication/token/.

From here, we’ll use Postman to make requests to the API, as we’ll have to inform the token in our requests.

Access Postman and make a POST request to the url 127.0.0.1:8000/api/v1/authentication/token/ passing the username/password in the request body:

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

When making the request informing the user and password you created in Django Admin, an Access Token and a Verify Token will be returned, however, in this tutorial we’ll only use the access token:

Copy the access token and make a new request on the route 127.0.0.1:8000/api/v1/todos passing the copied token in Authorization > Bearer Token, as shown in the image below:

With this, only authenticated users can access our tasks. But what if I want some user to have read-only permission, but not data modification? that is, can do a GET, but not a PUT? To solve this problem, we’ll use user permissions.

## User Permissions

At this point only authenticated users can use the API, however, we want to restrict access for these users. For example, a certain user may only have read permission GET, while another user can read and create new tasks GET and POST, while another type of user can do all actions. For this, we’ll use Django user permissions.

Let’s create two examples, the first will be a group of users that can only do GET and the second with all permissions.

Access Django Admin
Click on “Groups”
Create a group called "read_only" and give the permission Todo_Api | todo | Can view todo
Save
Repeat the process, now create a group called "full_access" and give the permissions: Todo_Api | todo | Can view todo
Todo_Api | todo | Can add todo
Todo_Api | todo | Can delete todo
Todo_Api | todo | Can change todo

Example of creating the “full_access” group:

Now we have two user groups with different permissions, this is the best practice for user permission management.

Now, we need to inform in the code that users besides being authenticated must have permission to execute actions in the API.

Inside app create a file called permissions.py and insert the code below:

# 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, '')

This code overwrites the has_permission function inherited from permissions.BasePermission. This function should return true or false. The code checks if the user has attached permission and returns true or false.

Finally, let’s add this permission class to our views file. In the file todo_api/views.py import the GlobalDefaultPermission class created previously and include it in the permission_classes. The code should look like this:

# 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

# Tests

In Django Admin, create a user and put them in the read_only group, it will work normally, then try to register a new task, you won’t have permission. After that, add the full_access group to the user and try again, you’ll be able to create the task.

Example of access attempt with a user without permission:

Now with the user being part of the read_only group:

Thus, our API is complete. We perform CRUD operations with authenticated users and protected routes.

# Conclusion

In this article we learned to use Django REST framework to create a REST API in a simple, secure and professional way. The work of a Backend developer is often tied to CRUD operations in the database, plus data modeling and application security. This API doesn’t aim to exhaust all development best practices, but to guide beginning developers about practices used in the market.

# Next steps

We can always improve our project, in the future we’ll implement some functionalities, such as:

Flake8 linter configuration for code standardization according to PEP 8
Create API documentation with Swagger
Create a Dockerfile to run the application as a container
Deploy the API on AWS with a complete Pipeline (CodeCommit + CodePipeline + CodeBuild + ECR + ECS with Fargate)

These contents will be published soon here on the blog.

I’ll be waiting for you. 😁

What is Linux and what are Linux distributions

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

Understand what Linux is and what Linux distributions are in a brief and succinct way.

# What is Linux?

Linux is a Kernel, created in 1991 by Linus Torvalds.

Kernel is the operating system component responsible for “talking” to the hardware, it’s the bridge that connects the “physical” part of the computer with the “logical” part.

# Linux Distributions

The Kernel is just one part of a Linux distribution, responsible for hardware communication with the operating system’s application layer. On the other hand, a Linux distribution is the use of the Linux Kernel with other tools, in order to create a usable operating system, with interface, applications, administrative tools and various other functionalities.

Some examples of Linux distributions:

Debian
RedHat
openSUSE
Slackware

# Conclusion

Linux is the kernel, the core of the system. It handles communication between hardware (CPU, Memory and Devices) and the logical part of the system (applications).

A Linux Distribution is a collection of software that uses the Linux Kernel, bringing to life a usable operating system based on the Linux Kernel.

It’s worth noting that this post doesn’t aim to exhaust the understanding of what Linux and Linux Distributions are, it’s just an overview of a very broad topic discussed in the community.

# Want to know more about the topic?

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

How to Host a Static Website on Amazon S3

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

Learn how to host your static website on Amazon S3 quickly and cost-effectively.

# Introduction

Amazon S3 (Simple Storage Service) is an excellent option for hosting static websites. It’s cost-effective, scalable, and easy to configure. In this guide, you’ll learn how to set up static website hosting on S3.

# What You’ll Need

AWS account
Static website (HTML, CSS, JS files)
Domain name (optional)

# Step-by-Step Guide

## 1. Create an S3 Bucket

Access the AWS Console
Navigate to S3 service
Click “Create bucket”
Choose a unique name for your bucket
Select your preferred region
Uncheck “Block all public access”
Click “Create bucket”

## 2. Upload Your Website Files

Open your created bucket
Click “Upload”
Add your website files
Make sure you have an index.html file

## 3. Configure Static Website Hosting

In your bucket, go to “Properties” tab
Scroll down to “Static website hosting”
Click “Edit”
Select “Enable”
Set index document: index.html
Set error document: error.html (optional)
Save changes

## 4. Configure Bucket Policy

Add this policy to make your files publicly readable:

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

Replace YOUR-BUCKET-NAME with your actual bucket name.

## 5. Access Your Website

Your website will be available at:

http://YOUR-BUCKET-NAME.s3-website-REGION.amazonaws.com

# Adding a Custom Domain

To use your own domain:

Configure Route 53 or your DNS provider
Create a CNAME record pointing to your S3 endpoint
Consider using CloudFront for HTTPS and better performance

# Benefits of S3 Hosting

Low cost: Pay only for storage and bandwidth used
High availability: 99.999999999% (11 9’s) durability
Scalability: Handles traffic spikes automatically
Easy deployment: Simple file upload process

# Limitations

Only supports static content
No server-side processing
Limited to HTTP (HTTPS requires CloudFront)

# Conclusion

Amazon S3 is an excellent choice for hosting static websites. It’s simple to set up, cost-effective, and highly reliable. For more advanced features like HTTPS and CDN, consider adding CloudFront to your setup.

Need help with AWS or web development? Feel free to contact me!

Cloud Computing Service Models: IaaS, PaaS, and SaaS

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

Understand the differences between IaaS, PaaS, and SaaS and choose the best model for your project.

# Introduction

Cloud computing revolutionized how we consume and manage IT resources. Instead of purchasing and maintaining physical servers, we can rent computing resources as needed. There are three main service models, each offering different levels of control and management.

# The Three Service Models

## 1. IaaS (Infrastructure as a Service)

What it is: Provides basic computing infrastructure - virtual machines, storage, networks, and operating systems.

What you manage:

Applications
Data
Runtime
Middleware
Operating System

What the provider manages:

Virtualization
Servers
Storage
Networking

Examples:

Amazon EC2
Google Compute Engine
Microsoft Azure VMs

When to use:

You need maximum control over the environment
Custom applications requiring specific configurations
Migration of existing applications to the cloud

## 2. PaaS (Platform as a Service)

What it is: Provides a development and deployment platform, including runtime environment, development tools, and database management.

What you manage:

Applications
Data

What the provider manages:

Runtime
Middleware
Operating System
Virtualization
Servers
Storage
Networking

Examples:

Google App Engine
Heroku
AWS Elastic Beanstalk

When to use:

Rapid application development
Focus on code, not infrastructure
Development teams without DevOps expertise

## 3. SaaS (Software as a Service)

What it is: Complete applications delivered over the internet, ready to use.

What you manage:

Data and user access

What the provider manages:

Everything else

Examples:

Google Workspace
Microsoft 365
Salesforce

When to use:

Standard business applications
Quick implementation without development
Focus on using the tool, not maintaining it

# Comparison Table

Aspect	IaaS	PaaS	SaaS
Control	High	Medium	Low
Flexibility	High	Medium	Low
Management Complexity	High	Medium	Low
Time to Market	Slow	Fast	Immediate
Cost	Variable	Medium	Predictable

# Choosing the Right Model

## Choose IaaS when:

You need complete control over the environment
You have specific compliance requirements
You’re migrating legacy applications

## Choose PaaS when:

You want to focus on development
You need to deploy applications quickly
You have a development team but limited DevOps

## Choose SaaS when:

You need standard business applications
You want minimal IT management
Quick implementation is priority

# Hybrid Approaches

Many companies use a combination of models:

SaaS for office applications (email, documents)
PaaS for custom application development
IaaS for specific infrastructure needs

# Conclusion

Each cloud service model has its place depending on your needs, technical expertise, and business objectives. The key is understanding what level of control and management you need versus what you’re willing to delegate to the cloud provider.

Understanding these models helps make informed decisions about cloud strategy and choosing the right services for each use case.

Want to learn more about cloud computing? Check out my other posts or get in touch!