During my summer holidays I decided to give a new look to my blog, I decided to switch to Hugo and move from GitHub Pages to Cloudflare (but considering the latest events I don’t know if it’s been a good choice…).

So I started to work a lot on it, first because I needed to learn how Hugo works and because in my mind I wanted to enhance it. I started to add my experience page, a page with the few talks I did. I studied how to customize some pages with Hugo partials, I created a dynamic SVG and I optimized for SEO and a lot of other stuff. Basically I fell into a huge rabbit hole. gif

I started to translate my Italian articles to English, because I think it’s ugly to have mixed languages on my blog. Not having constant access to my laptop made it really hard and 2 weeks were few (in the meanwhile, like two/three months ago I bought a new laptop… because I’m missing x86_64 arch but primarily I wanted to come back to Linux, maybe I can write about that in a future post). Hence I got overwhelmed.

The holidays ended and I wasn’t really convinced about the new blog design, and I thought.. I can work on it, in the evening or during the weekends… so if I’m writing this post… you should already understand… I didn’t touch it. I started to become a little bit frustrated about it… so I understood I needed to declutter. Consequently I fell into the same rabbit hole… but this time with a very defined goal in my mind: to have the blog fully in English and as minimalistic as possible (fortunately I did some translation during the summer).

So now after this huge intro and this sort of personal retrospective I want to welcome you to my new blog, and I hope you like it. I promise you, I will try to be more productive… and stop procrastinating.

See you soon. Bye.

📍 Where: Bologna, Italy

🕛 When: 24 June 2025

🗣️ Language: ITA 🇮🇹

In ambienti Kubernetes multi-cluster, correlare eventi e risolvere problemi è complesso: i servizi distribuiti generano enormi volumi di log frammentati tra cluster diversi, mettendo in difficoltà le soluzioni di logging tradizionali sia per prestazioni che per storage.

Questo talk dimostra come Grafana Loki, una soluzione open source progettata per garantire il pieno controllo sui propri dati, permetta di costruire un sistema di logging centralizzato. Presenterò un caso reale di implementazione in una cluster mesh, evidenziando come la sua architettura basata su etichette e storage distribuito consenta di gestire efficacemente i log.

Durante la sessione verranno mostrate le tecniche di implementazione di Loki in ambiente multi-cluster, i pattern per correlare efficacemente i log tra servizi distribuiti e le strategie di ottimizzazione per gestire grandi volumi di dati, il tutto con un approccio cloud native.

Scopri di più

📍 Where: Online

🕛 When: 19 October 2023

🗣️ Language: ITA 🇮🇹

In un mondo in cui lo sviluppo del software è sempre più veloce e sempre più importante per ogni tipo di business, la qualità del codice e la gestione del debito tecnico sono diventati aspetti essenziali, e SonarQube, piattaforma leader nell’analisi statica del codice, di cui useremo la versione gratuita Community Edition durante il talk, rappresenta uno strumento chiave per affrontare queste sfide.

Esploreremo l’importanza dell’analisi statica del codice, i benefici che ne derivano e come SonarQube si inserisce in questo contesto. Forniremo una panoramica su come questo strumento può essere integrato nel ciclo di vita dello sviluppo del software, con una particolare attenzione su come utilizzarlo al meglio per migliorare la qualità del codice e ridurre il debito tecnico, e mettendo in evidenza i benefici per gli sviluppatori, i team di sviluppo e l’intera organizzazione.

Nello specifico, approfondiremo i seguenti argomenti:

• Cosa è l’analisi statica del codice e perché è importante
• Come integrare l’analisi statica del codice nel ciclo di vita dello sviluppo del software
• Introduzione a SonarQube: funzionalità e vantaggi
• Esempi pratici di utilizzo di SonarQube in un progetto reale
• Best practice per l’uso di SonarQube

Scopri di più

What is Cosign?

Cosign, a tool from the Sigstore project, was created with the goal of making the signing and verification of Docker images simple and secure. This tool is vital to ensure that the code deployed in production is the exact replica of the original code, free from malicious modifications. With just a few simple commands, Cosign democratizes the use of public-key cryptography, making it accessible even to teams with only basic security expertise. Beyond signing and verification, Cosign goes further by offering key and signature transparency, making it easier to verify signatures and ensuring that no changes to signed images go unnoticed. This robust functionality makes Cosign an indispensable tool in the toolbox of any security-conscious DevOps team, providing a strong line of defense against software supply chain attacks.

Why is Docker Image Signing Useful?

Signing Docker images is a crucial step toward building a secure software supply chain. This practice raises the barrier against potential threats, ensuring the authenticity and integrity of containers. It acts as a strong verification mechanism, ensuring that the code ready to run or deploy is exactly the original, immune from unauthorized or malicious modifications. Docker image signing is essential for preventing Man-in-the-Middle (MitM) attacks, where attackers might attempt to inject malicious code while images transit over the network. It also aids in audits and compliance, offering an immutable record of signed and verified images, thereby providing full traceability and clear accountability. This is particularly useful in regulated or high-security environments, where traceability and compliance are crucial. With the exponential growth of containerized environments, signing Docker images with Cosign has become a key element in maintaining a secure and resilient software supply chain, allowing organizations to operate with greater confidence in the integrity of their systems.

How Does Cosign Work?

Cosign works by generating a pair of cryptographic keys: a private key to sign Docker images and a public key to verify them. When you sign a Docker image with Cosign, both the image and the signature are stored in a container registry. Later, anyone wishing to verify the image can use the public key to confirm that it was signed with the corresponding private key and has not been altered. Cosign can be easily integrated into CI/CD pipelines, enabling automatic signing and verification of images during the deployment process. Additionally, Cosign can interface with the Sigstore registry for even stronger signature transparency, offering a complete solution for managing Docker image security within the software supply chain.

How to Sign a Docker Image with Cosign

In this section, we’ll illustrate how to sign a Docker image with Cosign using a GitHub Action. Before getting started, make sure you have installed the latest version of Cosign. You can download the binary from GitHub or install it via Homebrew:

brew install cosign

Then, create a token on GitHub and export it as an environment variable:

export GITHUB_TOKEN=<token>

Now, generate the keys we will use in the GitHub Action. Thanks to the previously exported token, the Cosign command will insert the generated keys into the project’s secrets, allowing them to be used in the action:

cosign generate-key-pair github://<owner>/<project>

Next, create the GitHub Action. Create a file called docker-publish-and-sign.yml in your project’s .github/workflows directory, and insert the following code:

This GitHub Action follows a precise sequence of operations to ensure the Docker image is securely built, published, and signed:

• Checkout: Retrieves the source code from the GitHub repository.
• Set up Docker Buildx: Prepares the environment for building the image with Docker Buildx.
• Install Cosign: Installs Cosign in the runtime environment to enable image signing.
• Login to GitHub Container Registry: Logs in to the GitHub Container Registry (GHCR) to publish the Docker image.
• Build and Publish: Builds and publishes the Docker image to GHCR, using the GitHub run ID as the image tag.
• Sign the Image: Signs the Docker image using the private key, and the signature is stored in the registry.

To verify the signed image, run the following command:

cosign verify --key <public-key> <image>

The Sigstore Project

Sigstore is an open-source project that aims to raise the bar for supply chain security. Its mission is to provide reliable and transparent tools for signing and verifying software artifacts. Cosign is one of the solutions offered by Sigstore, providing a secure and transparent method for signing and verifying Docker images and other artifacts. The Sigstore initiative, backed by an active and collaborative community, is constantly innovating to make the software supply chain more resilient to attacks and aligned with best security practices.

Conclusions

The integrity of the software supply chain is a fundamental requirement for ensuring security in the modern era of software development. Tools like Cosign, supported by initiatives like Sigstore, represent significant steps forward in creating a more robust and secure supply chain, giving DevOps professionals the tools they need to effectively mitigate risks associated with supply chain attacks.

If you’ve followed this article to this point, you should now have a clear understanding of how to sign your Docker images and how to verify them. I hope this article has been helpful, and if you have any questions or suggestions, don’t hesitate to contact me.

The procedure described here is no longer supported. The kubernetes package has changed repository. For more information, please refer to the official documentation.

In a world where containerization is becoming increasingly central, having a solid understanding of how to configure Kubernetes is essential. In this article, I’ll guide you step by step through installing a Kubernetes cluster using containerd as the runtime.
And if you’re wondering, “Why containerd?”, the answer is simple: it’s lightweight, efficient, and perfectly integrated with Kubernetes.

Recently, I received the ZimaBoard. Motivated by the excitement of experimenting, I immediately installed Proxmox and created a Kubernetes cluster with containerd as the runtime. And that’s how the idea for this article was born.

I started by creating two virtual machines. Here are the specifications:

• Operating system: Ubuntu 20.04
• CPU: 2 vCPU
• Memory: 4GB
• Disk space: 20GB

Before proceeding, let’s make sure our virtual machines can communicate with each other. Once verified, we’re ready to begin.

Installing containerd

Containerd is the backbone of our cluster—the foundation on which all our containers will run. Let’s install it on our machines:

Prepare for installation:

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

Add Docker’s official GPG key:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Add the official Docker repository to our sources list:

echo \
    "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
    "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Finally, install containerd:

sudo apt-get update
sudo apt-get install containerd.io -y

Installing kubeadm, kubelet, and kubectl

These three components are the beating heart of Kubernetes. kubeadm helps us set up the cluster, kubelet ensures that all containers run correctly, and kubectl is our command-line interface for managing the cluster.

curl -fsSL https://dl.k8s.io/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

Disabling Swap

Kubernetes prefers swap to be disabled, as it can interfere with pod scheduling, especially in low-memory scenarios.

sudo swapoff -a

sudo nano /etc/fstab

(In the editor, comment out the line referring to swap by adding a # at the beginning of the line.)

Configuring Kernel Modules

We need to enable some Linux kernel modules to make everything work correctly.

sudo modprobe overlay
sudo modprobe br_netfilter

cat <<EOF | sudo tee /etc/modules-load.d/containerd.conf
overlay
br_netfilter
EOF

cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sudo sysctl --system

Configure containerd

Let’s make sure containerd is properly configured to interact with Kubernetes:

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl enable containerd

Configuring the Control Plane

Here comes the most exciting moment! We are about to initialize our Kubernetes cluster.

sudo systemctl enable kubelet

sudo kubeadm init --pod-network-cidr=192.168.0.0/16

(Don’t forget to write down the join command shown in the output! We’ll use it to add other nodes to the cluster.)

Installing Calico as CNI

Calico is one of the most popular Network Interfaces for Kubernetes. It helps manage communication between pods.

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml

If you’ve made it this far, you now have a fully functional Kubernetes cluster with containerd as the runtime. I hope this article has been helpful, and if you have any questions or suggestions, don’t hesitate to contact me.

RPC, short for Remote Procedure Call, is a protocol that allows one piece of software to request a service exposed by another piece of software.
These two pieces of software can reside on the same machine or on different machines, even across different networks.

In essence, an RPC call consists of invoking a function or procedure hosted on a server, a separate device, or inside a container.
When an RPC call is made, the underlying system handles the entire communication process between the two devices, making the remote procedure virtually indistinguishable from a local one from the developer’s perspective.

RPC is fundamental in many situations, such as:

• Distributed data storage systems
• Web services
• Distributed computing projects
• Operating systems
• Microservices

The Value of RPC

Adopting RPC offers numerous benefits, making it a strong choice in various contexts.
First of all, it abstracts away the complexity of networking: RPC hides the details of the network system, allowing developers to focus on application logic.
Additionally, RPC promotes a modular approach to software development, where each service can be developed, tested, and deployed independently.
Finally, thanks to its nature, RPC facilitates interoperability between different technologies and programming languages, simplifying integration between various systems or components.

JSON RPC: An Innovation in RPC

JSON RPC takes the concept of RPC to a new level, introducing flexibility and interactivity.
This data transmission protocol uses the JSON (JavaScript Object Notation) format to encode RPC messages, making them lightweight, easy to read and write, and independent of the programming language being used.

The protocol follows precise rules: every RPC call is encoded as a JSON object that must include the following properties:

• method: specifies the name of the method to invoke
• params: an array or object representing the method parameters
• id: a unique identifier for the call
• jsonrpc: specifies the version of the JSON RPC protocol

The response, also encoded in JSON, returns either the result of the invoked method or error details in case of failure. It includes the following properties:

• jsonrpc: specifies the version of the JSON RPC protocol
• id: a unique identifier for the call
• result: contains the result of the call, which may be an object. If an error occurs, this property will not be present
• error: returned in case of an error, with the following structure:
  • code: a number indicating the type of error. You can check the list of possible error codes and their meaning at this link
  • message: a short message describing the error
  • data: an object providing additional details about the error, optional

For more insights and further details about the protocol, I encourage you to consult the official JSON RPC documentation.

Detailed Analysis of JSON RPC

The JSON RPC protocol stands out from other RPC solutions due to its flexibility and interoperability.
It is not tied to a specific programming language or transport protocol.
In fact, it can be used with any language and transported over any protocol, offering unprecedented flexibility.
The protocol’s efficiency is further enhanced by its support for batch calls or notification calls, optimizing resource usage.

JRPC: Simplifying the Use of JSON RPC

JRPC is a project I am developing with the goal of making the implementation of the JSON RPC protocol more straightforward and intuitive.
This project consists of two key components: a server library and a client library, created to simplify the integration of the JSON RPC protocol into software applications.
The server library efficiently manages RPC requests, while the client library facilitates the processing and handling of RPC calls.
To further accelerate client-side implementation, I am also developing a CLI.

Here’s a clear and concise example of how it works:

For the server, based on Fastify:

...
const jrpcServer = new Server({
    name: 'jrpc-server',
    version: '1.0.0',
    description: 'demo server',
});

jrpcServer.addMethod({
    "name": "hello",
    "description": "A simple hello world method",
    "params": [
        {
            "name": "name",
            "description": "The name of the person to say hello to",
            "schema": {
                "type": [
                    "string",
                    "null"
                ]
            }
        }
    ],
    "result": {
        "name": "result",
        "description": "The result of the hello world method",
        "schema": {
            "type": "string"
        }
    }
}, (name?: string): string => {
    if (!name) {
        return 'Hello World!';
    }
    return `Hello ${name}!`;
});

server.post('/jrpc', async (request, reply) => {
    const {body} = request;
    const result = await jrpcServer.executeRequest(JSON.stringify(body));
    reply.send(result);
})
...

For the client:

...
export interface DemoRpcMethods {
    hello(name?: string): Promise<string>;
}

(async () => {
    ...
    const client = new JRPCClient<DemoRpcMethods>("http://127.0.0.1:3000/jrpc", resolver);
    const proxy = client.createProxy();
    console.log(await proxy.hello());
    console.log(await proxy.hello('Demo'));
})();

As you can see from the client code, it is enough to define an interface that describes the RPC methods, and the library takes care of the rest, eliminating the need to manually define the request payload.

Using the CLI allows you to automatically generate the interface from the schema produced by the server, further simplifying the process.

For more details, visit my GitHub to see the full demo code.

Conclusion

In conclusion, JRPC is my contribution to the community of developers working with JSON RPC. I firmly believe that collaboration is the key to developing high-quality software, and for this reason, I invite everyone to contribute to the project. Whether you have an idea for a new feature, a bug report, or a fix, every contribution is valuable and makes a difference.

I’m a big fan of technology, a developer, and someone who loves to create new things. I’ve been lucky to work in many different areas of technology, and each one has taught me something new. I’ve learned how technology changes the way we live and work, and I’m always amazed by its power and potential.

I love programming, especially when it comes to working with cloud technologies like containerization and Kubernetes. I’m always looking for new ways to build better and more efficient systems using these tools.

I’m also really interested in how we design software and systems. I believe that good design and clean code are crucial for successful software. I enjoy learning about different design patterns, like hexagonal architecture, which can help us build more reliable and easy-to-maintain systems.

In my spare time, I like to experiment with things like Internet of Things (IoT), home automation, and electronics. I love playing with microcontrollers like Arduino and ESP32, and using them to make my home smarter and more responsive.

One of my hobbies is 3D printing. I find it amazing how we can turn a digital design into a real, physical object. It’s a great example of how technology is bringing the digital and physical worlds closer together.

On this blog, I’ll be sharing my experiences, discoveries, and thoughts about technology. Whether it’s a new cloud solution I’ve found, a design pattern I’ve been studying, an IoT project I’ve been working on, or a new 3D print, I’ll be talking about it here.

I invite you to join me as I explore the world of technology. Whether you’re a tech enthusiast yourself or just curious, I hope you’ll find something here that inspires and interests you.

Welcome to my world, Marco Ferraioli A.K.A. ParanoiaSystem

From this experience came the idea to create a tool that automated this process: k8s-aws-ecr-secret-updater. This tool is a Kubernetes cronjob, designed to automatically update the AWS ECR repository access credentials.

Cronjob Configuration

The YAML code to create the cronjob consists of several parts, which I will now analyze piece by piece:

A Role that has permission to get, create, and delete secrets and get and update ServiceAccounts.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: k8sawsecrsecretupdater
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "create", "delete"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["get", "patch"]

A key component of this configuration is the k8sawsecrsecretupdater role. This role is fundamental for authorization within the Kubernetes namespace, allowing the cronjob to perform specific operations on certain resources.

In particular, the k8sawsecrsecretupdater role has the following permissions:

1. It has permissions to get (get), create (create), and delete (delete) Secrets. This is crucial because the cronjob needs to be able to create and delete AWS ECR credentials, which are stored as secrets in Kubernetes.
2. It has permissions to get (get) and update (patch) ServiceAccounts. The cronjob needs to be able to manage service accounts in order to associate the AWS ECR credentials with the service that runs the cronjob.

Creating a specific role for these operations ensures that the cronjob has exactly the permissions it needs to do its job, without granting it access to unnecessary resources. This approach is in line with the principle of least privilege, a common security practice that limits access to resources only to what is strictly necessary to perform a specific task. This helps to minimize the potential impact of a possible attack.

ServiceAccount to be used by the job and cronjob.

apiVersion: v1
kind: ServiceAccount
metadata:
 name: k8sawsecrsecretupdater

RoleBinding to associate the Role with the ServiceAccount.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: k8sawsecrsecretupdater
subjects:
  - kind: ServiceAccount
    name: k8sawsecrsecretupdater
roleRef:
  kind: Role
  name: k8sawsecrsecretupdater
  apiGroup: rbac.authorization.k8s.io

Job that creates the secret.

apiVersion: batch/v1
kind: Job
metadata:
  name: k8sawsecrsecretupdater
spec:
  backoffLimit: 4
  template:
    spec:
      serviceAccountName: k8sawsecrsecretupdater
      restartPolicy: Never
      containers:
      - name: k8sawsecrsecretupdater
        image: ghcr.io/paranoiasystem/k8s-aws-ecr-secret-updater:latest
        imagePullPolicy: Always
        env:
        - name: AWS_ACCOUNT
          value: 'YourAwsAccountID'
        - name: AWS_ACCESS_KEY_ID
          value: YourAccessKeyID
        - name: AWS_SECRET_ACCESS_KEY
          value: YourSecretAccessKey
        - name: AWS_REGION
          value: YourRegion

CronJob that runs the Job every 6 hours.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: k8sawsecrsecretupdater
spec:
  schedule: "0 */6 * * *"
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: k8sawsecrsecretupdater
          restartPolicy: Never
          containers:
          - name: k8sawsecrsecretupdater
            image: ghcr.io/paranoiasystem/k8s-aws-ecr-secret-updater:latest
            imagePullPolicy: Always
            env:
            - name: AWS_ACCOUNT
              value: 'YourAwsAccountID'
            - name: AWS_ACCESS_KEY_ID
              value: YourAccess
            - name: AWS_SECRET_ACCESS_KEY
              value: YourSecretAccessKey
            - name: AWS_REGION
              value: YourRegion

Creating the Docker Image

The cronjob uses a specific Docker image to perform its task. This Docker image is built from the following Dockerfile:

FROM alpine

LABEL org.opencontainers.image.description `Docker image for refresh AWS ECR credentials in kubernetes cluster`

RUN apk update && apk add --update --no-cache \
    git \
    bash \
    curl \
    openssh \
    python3 \
    py3-pip \
    py-cryptography \
    wget \
    curl \
    jq 

# Install kubectl
RUN curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
RUN chmod +x ./kubectl
RUN mv ./kubectl /usr/local/bin/kubectl

# Install AWSCLI
RUN pip install --upgrade pip && \
    pip install --upgrade awscli

WORKDIR /scripts
COPY scripts/ /scripts

ENTRYPOINT ["bash", "/scripts/entrypoint.sh"]

In the Dockerfile, starting from an Alpine base image, the necessary tools are installed, including git, bash, curl, openssh, python3, py3-pip, py-cryptography, wget, curl, jq. Also, kubectl and AWSCLI are installed for interaction with Kubernetes and AWS, respectively.

Subsequently, the working directory is set to /scripts and the contents of the local /scripts directory are copied. Finally, an ENTRYPOINT is defined that starts the entrypoint.sh script when the container is run.

Execution of the Script

When the cronjob is run, it starts the bash script contained in the Docker image. This script checks for the existence of a secret called "regcred". If it exists, it deletes it and creates a new one. If it doesn’t exist, it creates it. Below is the script:

#!/bin/bash

create_secret() {
  kubectl create secret docker-registry regcred \
    --docker-server=${AWS_ACCOUNT}.dkr.ecr.${AWS_REGION}.amazonaws.com \
    --docker-username=AWS \
    --docker-password=$(aws ecr get-login-password --region ${AWS_REGION})
}

# Check if the secret exists
if kubectl get secret regcred; then
  # If it exists, delete it
  kubectl delete secret regcred
  # Create the secret again
  create_secret
else
  # If it doesn't exist, create it
  create_secret
fi

Installing k8s-aws-ecr-secret-updater on Kubernetes

To use the k8s-aws-ecr-secret-updater in your Kubernetes environment, you need to follow some simple steps.

Let’s start by cloning the project’s GitHub repository onto your local system:

git clone https://github.com/paranoiasystem/k8s-aws-ecr-secret-updater

Next, you need to open and edit the install.yaml file present in the repository. In this file, you will need to set the following values:

• AWS_ACCOUNT: your AWS account ID.
• AWS_ACCESS_KEY_ID: your AWS access key.
• AWS_SECRET_ACCESS_KEY: your AWS secret access key.
• AWS_REGION: the AWS region where your ECR is located.

Once you have made these changes, save and exit the install.yaml file.

Now, to install the k8s-aws-ecr-secret-updater in your Kubernetes cluster, you need to execute the following command:

kubectl apply -n <destination_namespace> -f install.yaml

Remember to replace destination_namespace with the Kubernetes namespace where you want to install the cronjob.

Conclusions

This tool eliminates the need for manual updating of credentials, saving time and reducing the risk of errors. I hope this article and the tool I created can be of help to anyone dealing with a similar issue in managing AWS ECR credentials in a Kubernetes cluster.

📍 Where: Online

🕛 When: 1 February 2023

🗣️ Language: ITA 🇮🇹

In un mondo tecnologico in continua evoluzione, è sempre più importante essere in grado di scalare e adattare rapidamente i sistemi alle crescenti richieste degli utenti.

I Container offrono una soluzione efficace a questo problema, poiché permettono di isolare il software e farlo eseguire in modo indipendente su diversi sistemi operativi e hardware. Ciò consente alle applicazioni basate sui Container di passare facilmente tra gli ambienti di sviluppo, test e produzione.

Tra le migliori implementazioni della tecnologia dei Container c’è Docker, che offre una serie di funzionalità utili, a cui sarà difficile rinunciare dopo averle imparate ed utilizzate.

Docker Compose

In questo talk esploreremo Docker Compose, capiremo di cosa di tratta, come e quando usarlo.

Inoltre, partendo da un’applicazione reale la faremo girare, insieme, su Docker.

Nel dettaglio:

• Docker Compose
• Compose file
• Come scrivere un Docker Compose file
• Esempio pratico di applicazione reale che gira su Docker

Scopri di più

📍 Where: Online

🕛 When: 25 January 2023

🗣️ Language: ITA 🇮🇹

In un mondo tecnologico in continua evoluzione, è sempre più importante essere in grado di scalare e adattare rapidamente i sistemi alle crescenti richieste degli utenti.

I Container offrono una soluzione efficace a questo problema, poiché permettono di isolare il software e farlo eseguire in modo indipendente su diversi sistemi operativi e hardware. Ciò consente alle applicazioni basate sui Container di passare facilmente tra gli ambienti di sviluppo, test e produzione.

Tra le migliori implementazioni della tecnologia dei Container c’è Docker, che offre una serie di funzionalità utili, a cui sarà difficile rinunciare dopo averle imparate ed utilizzate.

Volumi e Network di Docker

In questo talk affronteremo i concetti di volume e network di Docker.

I volumi ci consentono di effettuare la persistenza dei dati e altre cose interessanti, che scoprirete durante la lezione.

I network, invece, ci consentono di creare reti virtuali all’interno delle quali far comunicare i nostri container.

In particolare:

• Volumi Docker
• Come creare e usare un volume
• Tipi di volume
• Network Docker
• Come creare una network
• Tipologie di rete
• Come usare una rete

Scopri di più

📍 Where: Online

🕛 When: 18 January 2023

🗣️ Language: ITA 🇮🇹

In un mondo tecnologico in continua evoluzione, è sempre più importante essere in grado di scalare e adattare rapidamente i sistemi alle crescenti richieste degli utenti.

I Container offrono una soluzione efficace a questo problema, poiché permettono di isolare il software e farlo eseguire in modo indipendente su diversi sistemi operativi e hardware. Ciò consente alle applicazioni basate sui Container di passare facilmente tra gli ambienti di sviluppo, test e produzione.

Tra le migliori implementazioni della tecnologia dei Container c’è Docker, che offre una serie di funzionalità utili, a cui sarà difficile rinunciare dopo averle imparate ed utilizzate.

Le basi di Docker

In questo talk esploreremo le basi di Docker: partiremo dal concetto di container, lo paragoneremo con le Virtual Machine, capiremo quali sono le differenze, i motivi per cui Docker è nato, i problemi che risolve e quando conviene utilizzarlo o meno.

Dopo aver installato insieme Docker, andremo ad analizzare la sua architettura ed inizieremo a prendere confidenza con la sua CLI (Command-line interface).

Nello specifico:

• Cosa sono i container
• Differenza con le Virtual Machine
• Un pò di storia dei container
• Installazione di Docker
• Docker CLI
• Comandi di base
• Le immagini Docker

Scopri di più