DEV Community: Vincent Caunegre

K3S

Vincent Caunegre — Wed, 23 Sep 2026 19:53:49 +0000

Looking for a straightforward, no-nonsense guide to Kubernetes and K3s? Here is everything you need to know—from core node architecture to everyday manifests and commands—all in one place.

K3S Architecture

A K3S cluster works with nodes, a node representing a machine like a VPS. A node can have 2 roles:

Server/Master node: responsible for managing the cluster.
Agent/Worker node: responsible for running pods.

Although a node can handle both roles, it is generally considered a best practice to keep them separate and never run workload pods on the master node.

Each type of node manages specific processes:

Master Node

kube-apiserver: The conductor of the cluster. All communication goes through it (for instance, kubectl talks to it when you run a command).
etcd: The memory of the cluster. It is a distributed key-value database (like SQLite by default in K3S).
kube-scheduler: Looks at newly created pods and decides which worker node should run them.
kube-controller-manager: Ensures that the current state of the cluster matches the desired state defined in manifests.

Worker Node

kubelet: Receives instructions from the master node and applies them to manage the pods on the local node.
kube-proxy: Manages network routing inside the node.

Kubernetes Workflow

You send a manifest (YAML) via kubectl to the API server.
The API server writes this state to etcd.
The scheduler sees a new task, chooses a worker node, and requests that node's kubelet to execute it.
The kubelet instructs the container runtime to start the container.

Kubernetes Node Commands

Command	Description
`kubectl get nodes`	Get all nodes in the current cluster
`kubectl top node`	Get resource usage of nodes
`kubectl describe node <node_name>`	Get detailed information about a node
`kubectl cordon <node_name>`	Mark a node as unschedulable

Kubernetes Resource Commands

Command	Description
`kubectl get <resource>`	Get all resources (pods, services, secrets...)
`kubectl get <resource> <name>`	Get a specific resource
`kubectl describe <resource> <name>`	Get detailed information on a resource

Labels and Annotations

In Kubernetes, a label is a key-value pair attached to objects (like pods). They can be displayed by adding --show-labels to kubectl get pods.

You can also filter pods by a specific label value:

kubectl get pods --selector="version=1" -n <namespace>

Keep in mind that labels are scoped to a namespace, so you cannot use labels as a substitute for namespaces.

ConfigMap

A ConfigMap is an object used to store non-confidential data in key-value pairs. Since it is stored in plain text, it should never be used for sensitive data like passwords or tokens.

How to create a ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  VERSION: "2"
  LOG_LEVEL: "DEBUG"

How to use it

For a single value, or if the environment variable name differs from the ConfigMap key:

spec:
  containers:
  - name: my-app
    image: my-app:v1
    env:
    - name: PURGE_MONTHS 
      valueFrom:
        configMapKeyRef:
          name: budget-config
          key: PURGE_THRESHOLD_MONTHS

For multiple values at once:

spec:
  containers:
  - name: my-app
    image: my-app:v1
    envFrom:
    - configMapRef:
        name: app-config

Other Usages, CLI Arguments:

spec:
  containers:
    - name: purge
      image: my-app:v1
      env:
        - name: PURGE_MODE
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: mode
      command: ["java", "-jar", "app.jar"]
      args: ["--operation=$(PURGE_MODE)"]

Mounted File:

First, define a ConfigMap where the key acts as a file name and the value acts as the file content:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-file
data:
  application-prod.yaml: |
    spring:
      datasource:
        url: jdbc:postgresql://postgres:5432/mydb
    app:
      purge:
        threshold: 12
    logging:
      level:
        root: WARN

Then, mount it inside your pod spec:

spec:
  containers:
  - name: my-app
    image: my-app:v1
    volumeMounts:
    - name: config-volume
      mountPath: "/app/config" 
      readOnly: true
  volumes:
  - name: config-volume
    configMap:
      name: app-config-file

Secrets

Secrets are designed for sensitive data such as passwords, OAuth tokens, or SSH keys.

How to create a Secret

While secrets can be declared in YAML (base64 encoded), creating them via the CLI is very common:

kubectl create secret generic db-access \
  --from-literal=DB_PASSWORD='MyPassword' \
  --from-literal=DB_USERNAME='dbuser'

How to use it

spec:
  containers:
  - name: my-app
    envFrom:
    - secretRef:
        name: db-access

Services

Pods are ephemeral by nature—their IP addresses change whenever they restart. Services provide a stable network interface and a fixed IP address to access a set of pods.

There are 3 main types of services:

ClusterIP: Exposes the service on a cluster-internal IP. Only reachable from within the cluster.
NodePort: Exposes the service on a static port on each node's IP, allowing external traffic to reach it.
LoadBalancer: Provisions an external load balancer (if supported by the cloud provider or environment) to expose the service publicly.

Ingress

An Ingress manages external HTTP/HTTPS access to services within a cluster, typically acting as a reverse proxy and handling TLS termination (HTTPS).

There are two main components:

The Ingress Controller: The actual reverse proxy running in the cluster (e.g., Traefik by default in K3S).
The Ingress Resource: Rules defining how domain names map to internal Kubernetes services.

Example of an Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  namespace: my-app
  annotations:
    kubernetes.io/ingress.class: traefik
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
    - hosts:
        - my-app.domain.app
      secretName: my-app-tls
  rules:
    - host: my-app.domain.app
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 8080

Storage

Persistent storage in Kubernetes relies on three core concepts:

StorageClass (SC): Defines how storage is provisioned (e.g., local disk, cloud disk).
PersistentVolume (PV): A piece of storage provisioned in the cluster.
PersistentVolumeClaim (PVC): A request for storage made by a user/application.

On K3S, local-path is the default StorageClass, which automatically provisions a folder on the node's local disk when a PVC is created:

NAME                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  108d

Create the PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: my-app
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Mount the PVC in your deployment spec:

spec:
  containers:
  - name: my-db
    image: postgres:15
    volumeMounts:
      - name: my-storage
        mountPath: /var/lib/postgresql/data
  volumes:
    - name: my-storage
      persistentVolumeClaim:
        claimName: my-pvc

Authentication and Authorization

Command	Description
kubectl get roles,clusterroles -A	See all Roles and ClusterRoles
kubectl get rolebindings,clusterrolebindings -A	See all RoleBindings and ClusterRoleBindings
kubectl describe clusterrole admin	Show details about a specific Role/ClusterRole
kubectl auth can-i create deployments	Check if you have permission to create deployments
kubectl auth can-i --list	See all your available permissions in the cluster

What is Docker ?

Vincent Caunegre — Thu, 19 Mar 2026 18:19:25 +0000

Docker is a platform that allows developers to package applications into standardized units called containers. It is useful for local testing or for deployment on cloud platforms.

The architecture of Docker

Docker is a set of tools to create containerized applications.
In Docker, we create an image, which is a stack of layers in the form of compressed .tar.gz folders. Each layer contains a "filesystem snapshot" of Linux, along with whiteouts—which act as "death notices" for deleted files.

OverlayFS is responsible for "mounting" the image. It traverses each layer from the most recent to the oldest, adding the elements it finds. However, if a specific element already exists in a higher layer or is marked as a whiteout, it is ignored. This process results in a "phantom" or unified view, which serves as the final mounted system.

If I run an alpine/jre image on my Ubuntu machine, a process is created that "believes" it is running on an Alpine system with a JRE (thanks to this filesystem "phantom"). It then executes a Java command on a JAR file within what it perceives to be its own local filesystem.

The Dockerfile

The dockerfile is the recipe used by docker to build an image. It has some properties like:

FROM: to define the base image
WORKDIR: Sets the working directory for all subsequent commands.
COPY: copy a file or a folder from local environment to a directory
RUN : Executes a command during the build process.
ENTRYPOINT : The main command that will always run when the container starts.
CMD : Provides default arguments for the ENTRYPOINT.
EXPOSE: documenting the port used by the application
as Builder : with a FROM, it inform docker to build this part for the next FROM, but not keeping it

The image version and deployment

Naming convention:

docker build -t [REGISTRY_URL]/[PROJECT_OR_ORG]/[REPO_NAME]:[TAG] .
Note: If [REGISTRY_URL] is omitted, Docker Hub is used by default.

But it can be simplified to docker build -t [REPO_NAME]:[TAG] . if you are on local environment.

The `latest`rule:

Never use latestas a unique version. It's a pointer, not a release.

Build with a real version (ex: 1.0.0).
(Optional) Re-tag it as latest if you want it to be the default.

Deploying to Docker Hub:

docker login
docker push [PROJECT_OR_ORG]/[REPO_NAME]:[TAG]

Deploying to GHCR (GitHub):

echo $MY_GITHUB_TOKEN | docker login ghcr.io -u [USERNAME] --password-stdin
docker tag [LOCAL_IMAGE] ghcr.io/[PROJECT_OR_ORG]/[REPO_NAME]:[TAG]
docker push ghcr.io/[PROJECT_OR_ORG]/[REPO_NAME]:[TAG]

Docker ports and networking

When you run a Docker image and want your application to be available from outside the container, you must map the ports. You choose a host port available on your machine and an internal port that the application uses inside the container:

docker run -d -p <HOST_PORT>:<INTERNAL_PORT> --name <NAME_OF_APP> <IMAGE_NAME>:<TAG>

Docker is responsible for bridging the host port and the internal port. As a result, your application works perfectly, "thinking" it is the only app on the machine. On a VPS, your app will be reachable at <VPS_IP>:<HOST_PORT>.

Important: For this to work, the application inside the container must listen on 0.0.0.0 and not 127.0.0.1.

With this command, if you are on a vps, your app will be available on :

Internal Networking (Isolation)

If you want a container (like a database) to be isolated from the public network while remaining accessible to your API, you should use a Docker network:

docker network create my-net
docker run -d --name db --network my-net -e POSTGRES_PASSWORD=pw postgres:15-alpine
docker run -d --name app --network my-net -p 80:8080 my-app

After that, your database is isolated from the internet. Only the containers inside my-net (like app) can connect to it using the container name db as the hostname (e.g., jdbc:postgresql://db:5432/mydb).

Volumes

By default, all files created inside a container is lost if the container is deleted. If you want to keep data permanently on Docker, you must use volumes.

How images works with volumes

When someone create an image, like a postgres or a mysql image, it can add VOLUME /path/to/data to precise to Docker that it wants the data from this path to be saved.

Then, when the image is launched in a container, Docker will automatically create a Volume, called anonymous volume, if there is no volume added in the command.

If we delete this container and recreate it with a command with the volume, it will point to the data from the volume in the last layer of the image, the temporary layer, in the path specified in the VOLUME line in the image.

There are 2 types of volumes, Bind Mounts and Named Volumes.

Bind Mounts (for development)

We link a folder from your host machine directly to a folder in the container.

Format : -v /path/to/host:/path/inside/container
Advantage : You see in realtime your files on your machine.

Named Volumes:

docker volume create volume_name
-v volume_name:/path/inside/container

Example : Postgresql

docker volume create pgdata
docker run -d --name app-db -e POSTGRES_PASSWORD=secret \ -v pgdata:/var/lib/postgresql/data postgres:17-alpine

Docker Compose

Docker Compose is the way provided by Docker to manage multiple containers with only one files.

The main concepts :

docker-compose.yml : A single text file that describes how to launch one or more containers.
*Service *: A container defined in the file.
Network : Docker Compose automatically creates a network so that your containers talk to each other with their service names.
Volumes : The definition of named volumes is also done in this file.

Action	Command
start	docker-compose up -d
stop	docker-compose down
logs for all containers	docker-compose logs -f

Example:

version: '3.8'

services:
  # 1. DB service
  app-db:
    image: postgres:17-alpine
    container_name: app-db
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: secret_password # <--- To be changed !
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data # <--- Named Volume
    networks:
      - app-network
    restart: always

  # 2. Java API Service
  app-api:
    image: your-java-api:latest
    container_name: app-api
    ports:
      - "8080:8080"
    environment:
      # The url use the name of "app-db"
      DB_URL: jdbc:postgresql://app-db:5432/appdb
      DB_USER: user
      DB_PASSWORD: secret_password
    depends_on:
      - app-db # <--- We check that the db started before starting the app
    networks:
      - app-network
    restart: always

# 3. Named Volume definition
volumes:
  pgdata:

# 4. Network definition
networks:
  app-network:
    driver: bridge

Debugging a docker container

Now that you have a working Docker environment, you should be able to debug a Docker container in case of failure:

Action	Command
see state for all containers	docker ps -a
get logs for a container	docker logs
clean unused containers, images and networks	docker system prune

Useful Linux Commands

Vincent Caunegre — Tue, 03 Mar 2026 21:30:27 +0000

In this article I will show you the commands that I use the most on my Ubuntu vps.

Navigation

Command	Action
`ls -alth`	show content of folder
`wc -l <path to file>`	display the number of lines in a file
`pushd <path>`	go to a directory and save the path in history
`popd`	rollback to previous directory from pushd
`dirs -v`	show pushd history
`cd -`	get back to previous directory (reset history)
`mkdir -p /folder/folder2`	create a new directory with non existing folders
`find . -name "*.yaml"`	find all files that end by ".yaml" in current directory

File editing

Command	Action
`pwd > test.txt`	send the content of a command to a file (erase the previous content)
`pwd >> test.txt`	add the content of a command to the next line of a file
pwd \| tee test.txt	same as pwd > test.txt but print it in cli
pwd \| tee -a test.txt	same as pwd >> test.txt but print it in cli
grep "ubuntu" test.txt \| wc -l	connect commands (for instance to get number of line with a word)

System

Command	Action
`ps aux`	list all processes for all users
ps aux \| grep	Find a running process by name
`top` and `htop`	List current running process by cpu usage
`free -m`	get memory usage
`df -h`	get volumes % still available, always check that biggest volume is not > 90%
sudo du -sh * \| sort -h	sort biggest folders
sudo du -ahx / \| sort -rh	head -n 20
sudo ss -tulpn \| grep :8080	find if a port is already used by a process, then kill it with `kill -15 <pid>`
`telnet <MACHINE IP> <PORT>`	from a machine, check if a port is open on another machine
`dig google.com`	check if a domain name is valid
`curl -v <url>`	execute an http request
`ip a`	see private and public ip adress

systemctl

Command	Action
`sudo systemctl start my-api.service`	start systemctl
`journalctl -u my-api.service -f`	show logs of a systemctl service in real time
`journalctl -u my-api.service -p err`	show only errors for a systemctl service
`sudo journalctl --vacuum-time=2d`	remove logs older than 2 days

How to deploy a Spring Boot app on fly.io

Vincent Caunegre — Sat, 04 Oct 2025 13:29:18 +0000

In this article I will show you how to deploy a spring boot application with a postgresql db on fly.io

Creating the Spring Boot project

On Spring Initializr we will need spring web, spring data jpa and postgresql driver for this project, you can also use jdbc if you want.

We will create a simple Product class

@Entity
@Table(name = "products")
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    private String description;

    private Float price;

// getters and setters
}

With this repository

public interface ProductRepository extends JpaRepository<Product, Long> {
}

and finally the controller

@RestController
@RequestMapping("/api/products")
public class ProductController {

    private final ProductRepository productRepository;

    public ProductController(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @GetMapping
    public List<Product> findAll() {
        return productRepository.findAll();
    }

    @GetMapping("/{id}")
    public Product findById(@PathVariable Long id) {
        return productRepository.findById(id).orElseThrow(()->new RuntimeException("Product not found"));
    }

    @PostMapping
    public Product createProduct(@RequestBody Product product)
    {
        return productRepository.save(product);
    }

    @DeleteMapping("/{id}")
    public void deleteById(@PathVariable Long id) {
        productRepository.deleteById(id);
    }
}

The application.yml file, I don't use a migration tool so I let hibernate generate the tables, but in production you should not do that.

spring:
  datasource:
    url: jdbc:postgresql://${PGHOST}:${PGPORT}/${PGDATABASE}
    username: ${PGUSER}
    password: ${PGPASSWORD}
  jpa:
    hibernate:
      ddl-auto: update
    open-in-view: false
    properties:
      hibernate:
        dialect: org.hibernate.dialect.PostgreSQLDialect

Deploying on fly.io

First you need to install flyctl here

Then create a dockerfile, I set the maximum ram to 512mb, you should adapt it to your app memory usage:

# Step 1: Create jar file that will be deployed
FROM maven:3.9.11-amazoncorretto-21 AS builder

WORKDIR /app

COPY pom.xml .

RUN mvn dependency:go-offline

COPY src ./src

RUN mvn clean package -DskipTests

# Step 2: Create final image
FROM eclipse-temurin:21-jre

WORKDIR /app

# Copy jar file build during the builder step
COPY --from=builder /app/target/*.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java","-XX:MaxRAM=512m","-XX:MaxMetaspaceSize=124m", "-jar", "app.jar"]

In cmd, run
fly auth login

then
fly launch
It will create the app on fly.io. However the app wont't start because we don't provide variables for db.

To do that, first run
fly postgres create
It will start a wizard in your terminal to create an unmanaged postgresql db. Follow it and at the end you will get some informations on the db you've created:

Username
Password
Hostname
Proxy port

Now go to your app -> secrets and add theses secrets from the previous infos:

PGUSER -> Username
PGPASSWORD -> Password
PGHOST -> Hostname (with the .internal)
PGPORT -> Proxy Port
PGDATABASE -> postgres

After doing that you can redeploy your app with fly deploy in your terminal. If it is successful, you can go to /api/products and see an empty array. If it is not working, go to the dashboard, in Logs & Errors tab to see what error is displayed.

Basic authentication in Spring Boot

Vincent Caunegre — Mon, 10 Feb 2025 22:04:32 +0000

Spring Security is responsible for authenticate and authorize Spring applications, it provide multiple way of doing authentication but Basic is probably the simplest.

With basic authentication, for every request made to the api, we send the user credentials in the headers, generally encoded with Base64 format.

Creating the Spring Boot application

We keep it simple with only spring web and spring security.

We will add a simple GET request:

package com.example.spring_basic;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DemoController {

    @GetMapping("/hello")
    public String hello(){
       return "hello world !";
    }
}

If we run the application and we inspect the logs, we can see that Spring is already handling security with a generated password

We can already test the request, for instance with IntelliJ Http request, and see that it works:

### GET request to example server
GET http://localhost:8080/hello
Authorization: Basic user <Generated password>

However this is not what we want, so let's add a new Spring Security Configuration:

package com.example.spring_basic;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;
import org.springframework.security.web.SecurityFilterChain;

import static org.springframework.security.config.Customizer.withDefaults;

@Configuration
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity httpSecurity) throws Exception {
        httpSecurity.httpBasic(withDefaults());
        httpSecurity.authorizeHttpRequests(http ->{
            http.requestMatchers("/users").permitAll();
            http.anyRequest().authenticated();
        });
        return httpSecurity.build();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public InMemoryUserDetailsManager inMemoryUserDetailsManager() {
        UserDetails user= User.builder().username("user")
                .password(passwordEncoder().encode("password"))
                .roles("USER").build();

        UserDetails admin=User.builder().username("admin")
                .password(passwordEncoder().encode("password"))
                .roles("USER","ADMIN").build();
        return new InMemoryUserDetailsManager(user, admin);
    }
}

First we recreate a SecurityFilterChain bean, for now we only add basic auth and require all requests to be authenticated.

Then we declare a PasswordEncoder bean that will be used to encode the password during the security process.

Then we declare a UserDetails implementation. For the moment we will not create custom UserDetails and User. You can see that we use the passwordEncoder to encode the "password" value. So when we will compare the provided password with the user password we will compare the encoded version of the password.

We can test the request by providing credentials:

### GET request to example server
GET http://localhost:8080/hello
Authorization: Basic user password

Use a database to store user

If we want to use a real database we must first add dependencies, in this case we will use spring data jpa and h2 file database

in pom.xml:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>

        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>2.3.232</version>
        </dependency>

With this in application.properties

spring.datasource.url=jdbc:h2:file:./data/demo
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=password

We will add a new User. We will implement UserDetails interface and to keep it simple, we will not add roles in our user case.


@Entity
@Table(name = "users")
public class User implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    private String password;

    public Long getId() {
        return id;
    }

    public User setId(Long id) {
        this.id = id;
        return this;
    }

    public String getUsername() {
        return username;
    }

    public User setUsername(String username) {
        this.username = username;
        return this;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return List.of(new SimpleGrantedAuthority("ROLE_USER"));
    }

    public String getPassword() {
        return password;
    }

    public User setPassword(String password) {
        this.password = password;
        return this;
    }
}

We will create a repository for this user:

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByUsername(String username);
}

And a Controller to create new users. Pay attention to inject a passwordEncoder to encrypt the password before saving it to database:

@RestController
@RequestMapping("/users")
public class UserController {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;

    public UserController(UserRepository userRepository, PasswordEncoder passwordEncoder) {
        this.userRepository = userRepository;
        this.passwordEncoder = passwordEncoder;
    }

    @PostMapping
    public User createUser(@RequestBody User user) {
        user.setPassword(passwordEncoder.encode(user.getPassword()));
        return userRepository.save(user);
    }
}

We will remove the InMemoryUserDetailsManager bean inside the SecurityConfig file, and create a new UserDetailService class

@Service
public class CustomUserDetailsService implements UserDetailsService {

    private final UserRepository userRepository;

    public CustomUserDetailsService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return userRepository.findByUsername(username).orElse(null);
    }
}

With this http request

POST http://localhost:8080/users
Content-Type: application/json

{
  "username": "user",
  "password": "password"
}

It should works, but how ?

Behind the scene

When we make the request, it flows through a filter chain with differents filters, when a filter detects the headers he wants, he can call the AuthenticationManager. In our case, when the BasicAuthenticationFilter receive a request with username and password, it call the AuthenticationManager with a non valided UsernamePasswordToken.

The AuthenticationManager will then find a provider that handle this token, in our case the DaoAuthenticationProvider. It will use the UserDetails to find User with the same username as the credentials, then encode the password and compare it with the credentials password. If it matchs, it will update the token, add it to the SecurityContext, and return the token to the manager, then to the filter.

You can find the source code here

DEV Community: Vincent Caunegre

K3S

K3S Architecture

Master Node

Worker Node

Kubernetes Workflow

Kubernetes Node Commands

Kubernetes Resource Commands

Labels and Annotations

ConfigMap

How to use it

Mounted File:

Secrets

How to create a Secret

Services

Ingress

Storage

Authentication and Authorization

What is Docker ?

The architecture of Docker

The Dockerfile

The image version and deployment

Naming convention:

The latestrule:

Deploying to Docker Hub:

Deploying to GHCR (GitHub):

Docker ports and networking

Internal Networking (Isolation)

Volumes

How images works with volumes

Bind Mounts (for development)

Named Volumes:

Example : Postgresql

Docker Compose

Example:

Debugging a docker container

Useful Linux Commands

Navigation

File editing

System

systemctl

How to deploy a Spring Boot app on fly.io

Creating the Spring Boot project

Deploying on fly.io

Basic authentication in Spring Boot

Creating the Spring Boot application

Use a database to store user

Behind the scene

The `latest`rule: