Forem: Hugo Bollon

I Rebuilt My Developer Portfolio with Nuxt 4 + Strapi and Made It Open Source

Hugo Bollon — Sat, 21 Mar 2026 11:46:45 +0000

If you've been putting off rebuilding your portfolio because it feels like a weekend project that always gets pushed to the following month, I understand. Mine sat on Vue 2 and CosmicJS for years. It still worked, but it carried the kind of technical debt that makes you hesitate every time someone asks for the repository.

This is the story of how I finally rebuilt it from scratch, why I made certain architectural decisions, and why I ended up open-sourcing it as a reusable Nuxt 4 + Strapi portfolio starter.

The Problem With Most Developer Portfolios

Here's a pattern I've noticed: developers spend a lot of energy on the initial build, then abandon the thing entirely. The portfolio accumulates outdated tech, unmaintained dependencies, and content that no longer reflects who they are.

The reasons are usually the same:

No CMS — updating content requires a code change, a commit, a deploy. That friction kills momentum.
Outdated stack — Vue 2, Create React App, Gatsby v2, Jekyll. Not inherently bad, but try explaining that to a recruiter who opens DevTools.
Poor SEO baseline — client-side rendered apps with no server-rendered meta tags, missing OG images, no sitemap. Google does eventually figure it out, but you're fighting it rather than working with it.
Hard to reuse — most portfolios are so tightly coupled to the original author's content that forking one means untangling dozens of hardcoded strings and personal data.

My old portfolio (github.com/hbollon/portfolio-vuejs) was a good project at the time. Vue 2, CosmicJS as the CMS. It worked. But every time I wanted to update my bio or add a new project, I found myself doing more than I wanted to do just to push a change. And the codebase had grown organically in ways that made it uncomfortable to share.

I wanted something different: a portfolio I'd actually enjoy maintaining, built on a stack I use professionally, with real content management, and structured so someone else could fork it and use it without major refactoring.

The Solution: An Open-Source Nuxt 4 + Strapi Portfolio Starter

GitHub: github.com/hbollon/portfolio-nuxt
Live demo: hugobollon.dev

The project is a statically generated developer portfolio built with Nuxt 4 and Strapi v5, fully open source under the MIT license. It's designed to be a working starting point, not just an inspiration screenshot. You fork it, point it at your own Strapi instance, fill in your content, and deploy.

Key Features

Nuxt 4 with SSG — fully pre-rendered HTML, deployed to S3 + CloudFront. No server runtime in production. Excellent Lighthouse scores by default.
Strapi v5 as headless CMS — content is fetched at build time only. Strapi is never exposed to end users. You get a full admin interface to manage projects, experience, education, and bio without touching code.
EN/FR internationalization — built-in support for two locales with @nuxtjs/i18n. UI strings live in local JSON files; editorial content (bio, projects, experience descriptions) is translated inside Strapi.
Space/cosmos dark theme — custom design system with a consistent token palette (deep blacks, nebula purples, electric blues). Glassmorphism cards, particle backgrounds via tsparticles, scroll-triggered animations.
Full SEO setup — automatic sitemap, hreflang for each locale, Open Graph and Twitter Card tags, JSON-LD structured data, canonical URLs. Everything handled by a useSeo() composable, configurable per-page from Strapi.
Umami analytics — privacy-friendly analytics as an alternative to Google Analytics. GDPR-compliant by design.
CI/CD with GitHub Actions + AWS OIDC — no static AWS credentials. The deployment workflow assumes an IAM role via OIDC token, syncs the build output to S3, and invalidates CloudFront.
Fallback content mode — if you want to run it locally without a Strapi instance, the build falls back to static content files. Useful for quickly evaluating the template.

Technical Highlights

Strapi consumed at build time only

This is a constraint I deliberately chose, and it simplifies a lot of things. During nuxt generate, Nuxt fetches all content from Strapi's REST API. The output is static HTML. No runtime API calls. No CORS configuration. No authentication tokens in the browser. Strapi stays entirely behind the build process.

This also means the content types are designed with forward compatibility in mind. Projects already have slug, fullDescription, and an SEO component which make it ready for detail pages when I decide to implement them, without any schema migration.

Custom Strapi composable instead of a module

Rather than pulling in @nuxtjs/strapi, I wrote a lightweight useStrapi() composable that wraps Nuxt's useFetch / useAsyncData with the API token passed as a header. It's about 50 lines of TypeScript, it does exactly what the project needs, and it avoids shipping authentication code that will never run.

Strapi v5 uses a flat API response format (no data.attributes wrapping), and the types in shared/types/strapi.ts reflect that directly. TypeScript strict mode is enforced so no any and no index access without guards.

Tailwind v4 configured purely in CSS

No tailwind.config.ts. Tailwind v4 uses @tailwindcss/vite as a Vite plugin and is configured via @theme blocks in app/assets/css/main.css. All design tokens (colors, gradients, shadows, animations) are CSS custom properties. Tailwind generates utility classes from them automatically.

@theme {
  --color-space-black: #0a0a0f;
  --color-nebula-purple: #a855f7;
  --shadow-glow-purple: 0 0 20px rgba(168, 85, 247, 0.5);
  --animate-float: float 6s ease-in-out infinite;
}

This approach is cleaner, more composable, and doesn't require a JavaScript file for design decisions.

Performance-first by design

SSG eliminates server response time. The critical rendering path targets under 75kb of gzipped JavaScript (Nuxt + Vue + app code + i18n). Tsparticles and analytics are loaded client-only and deferred after hydration. The site is fully readable without JavaScript — animations and interactivity layer on top.

Lighthouse targets: Performance > 95 on desktop, > 90 on mobile. Accessibility 100. SEO 100.

i18n architecture — hybrid approach

UI strings (nav labels, button text, static messages) live in local JSON files consumed by @nuxtjs/i18n. Editorial content (project descriptions, bio, job titles) is translated inside Strapi using its built-in i18n plugin. The build fetches each locale separately and generates separate URL paths: English at /, French at /fr/.

This hybrid approach avoids duplicating every editorial string in JSON files while still keeping UI strings version-controlled and reviewable in the codebase.

Infrastructure

Production runs on AWS: static output synced to a private S3 bucket, served through CloudFront with Origin Access Control. Strapi runs on an ARM EC2 instance (t4g.micro) behind Caddy, containerized with Docker Compose. Media uploads go to a separate S3 bucket served via a second CloudFront distribution. All infrastructure is Terraform-managed.

The CI/CD pipeline uses AWS OIDC which means no static credentials and no AWS_ACCESS_KEY_ID stored as a secret. The GitHub Actions workflow assumes an IAM role via OIDC token, which I consider a baseline security requirement for any workflow touching cloud resources.

Demo & Links

Live portfolio: hugobollon.dev
GitHub repository: github.com/hbollon/portfolio-nuxt

If this project saved you some time or inspired your own build, a star on GitHub helps more than you might think — it signals to others that the project is worth looking at, and it keeps me motivated to improve it.

⭐ Star the project on GitHub

Why Open Source

Open source has always been a big part of how I work and build things. I maintain and contribute to several projects, including go-edlib (edit distance algorithms in Go) and jgo (a DAG JSON parsing library for Go). Sharing tools, improving them in public, and making them useful to others is something I naturally gravitate toward.

This project follows the same logic. I built on top of countless open-source tools, and publishing it felt like a natural way to give something back. When I started, I couldn’t find a modern Nuxt 4 + Strapi portfolio that was both production-ready and reusable. Most examples were either too minimal or too tied to a specific personal setup.

There’s also a practical benefit: public code tends to be better code. Knowing that someone might fork this and rely on it pushes me to keep things clean, documented, and maintainable.

If you build something with it, I’d genuinely like to hear about it. Open an issue, leave a comment, or reach out.

Getting Started

git clone https://github.com/hbollon/portfolio-nuxt.git
cd portfolio-nuxt
cp .env.example .env.local
# Set STRAPI_URL, STRAPI_TOKEN, NUXT_PUBLIC_SITE_URL
# Leave blank to use fallback content for local evaluation

yarn install
yarn run dev

The Strapi data model is documented in specs/strapi-data-model.md. Content types, field definitions, required relations — it's all there.

Conclusion

Rebuilding a portfolio is one of those tasks that's easy to justify putting off indefinitely. I finally did it because I had a clear goal: a maintainable stack, real content management, solid SEO, and something useful to other developers.

The result is a Nuxt 4 + Strapi portfolio starter that I actually use in production, with deployment infrastructure I'd put in front of real traffic.

If you're building your own portfolio, fork it, adapt it, break it, improve it. That's what it's there for.

github.com/hbollon/portfolio-nuxt — contributions and feedback are welcome!

Deploy your Pulumi project using Docker and Dagger.io

Hugo Bollon — Wed, 14 Dec 2022 10:30:00 +0000

🕰️ In the previous episode

In the first part of this Dagger's series, I showed you what's Dagger.io, what's the features of it and it's benefits against others ci/cd solutions and finally the very basis of Dagger.

With this chapter, I will show you how we can overpower the CI/CD of any Pulumi project using Dagger.

🧰 Pulumi - An amazing IaC tool

First of all, I think that some of you may doesn't know what is Pulumi or even IaC (Infrastructure as Code) concept, so I will quickly present to you these two points.

Infrastructure as Code

Nowadays, IT extends to many areas, and so new needs are emerging leadingly to a necessity to adapt infrastructures in order to be able to support all of this.
They also have seen their prerequisites evolve given their multiplication and their increasingly large sizes. As a result, companies started wanting to automate and simplify their infrastructures.

To address this problem, Amazon unveiled in 2006 the concept of Infrastructure As Code (or IaC) allowing, on Amazon Web Services, the configuration of instances using computer code.
It was a revolution for infrastructure management and, although limited at the time, this method was quickly adopted by the market.
This event also coincides with the date of appearance of the DevOps movement in which it's part.

Most of the infrastructure as code tools are based on the use of descriptor files to organize the code which avoids duplication between environments. Some advanced tools support variability, the use of outputs and even deployment to several providers simultaneously.

There are three types of infrastructure as code:

Imperative: resources (instances, networks, etc.) are declared via a list of instructions in a defined order to obtain an expected result.
Functional: unlike the imperative mode, the order of the instructions does not matter. The resources are defined in such a way that their final configuration is as expected.
Based on the environment: the resources are declared in such a way that their state and their final configuration are consistent with the rest of the environment.

The advantages of IaC compared to traditional management are numerous, such as: cost reduction, the possibility of versioning the infrastructure, the speed of deployment and execution, the ability to collaborate, etc.
It also allows complete automation, in fact, once the process is launched, there is no longer any need for human intervention. This advantage not only limits the risks due to human error and therefore increases reliability, but also allows teams to focus on projects and less on the deployment of applications.

Pulumi

Pulumi is an open-source IaC tool. It can be used to create, manage and deploy an infrastructure on many cloud provider like AWS, GCP, Scaleway, etc.
It haves few strengths compared to others IaC solutions like Terraform for example.

First of all, Pulumi support many programming languages like Go, TypeScript, Python, Java, F# and few others.
This is a great advantage for Pulumi and one of the reasons why we begin to use it at Camptocamp because the presence of a programming language like Go, rather than a configuration language like HCL (language used by Terraform) allows much more flexibility and adaptability.

Furthermore, Pulumi has new native providers like AWS, Google, and others in order to get new versions the same day they are released.
Additionally, Pulumi also supports Terraform providers to maintain compatibility with any infrastructure built using Terraform.

Another very interesting advantage is the support of what they call “Dynamic Providers” which allows to easily extend an existing provider with new types of personalized resources and that by directly programming new CRUD operations.
This can allow new resources to be added, for example, while adding complex migration or configuration logic.

Finally, there are still many advantages to Pulumi such as the ease of carrying out tests thanks to the native frameworks of the programming languages provided for this usage, the presence of aliases allowing a resource to be renamed while maintaining compatibility with the state of the infrastructure, better integrations with mainstream IDEs like VSCode, etc.

⚡ Supercharge your Pulumi project thanks to Dagger

Now that you know IaC, Pulumi and of course Dagger (if not, you can check the first part of this blog series), we will see how we can create CI/CD pipelines for any Pulumi project using Dagger and CUE and finally how can we run them.
For that, I will present to you the Dagger architecture we have built at Camptocamp, it was designed to be complete and reusable. It may be too complex for small projects but if you understand it you will normally be able to create your own !

Important note: Initially Dagger.io was developed using Cuelang, an amazing and modern declarative language. Cue was also the only way to do pipelines with it. However, Dagger's team have recently transformed Dagger to be language agnostic.
We now have different SDKs: Go (the main one), CUE, Node.js and Python.
As of today, I advice you to choose the Go SDK if you don't really know which one to take. For the CUE one, I only recommend it to you if:

You like declarative language like YAML
You know CUE or want to learn it

For the following chapters, I will present our implementation which is made in CUE. However, it will be easy to transpose it to other SDKs if you understand it.

📦 The Pulumi package

In order to make a reusable and powerful Dagger project, we decided to create a "Pulumi" package which embeds our objects definitions like:

the Docker image
the container definition
the command object

As an exemple there is the command object definition:

// pulumi/command.cue
package pulumi

import (
    "dagger.io/dagger"
    "universe.dagger.io/bash"
    "universe.dagger.io/docker"
)

#Command: self = {
    image?: docker.#Image
    name:   string
    args: [...string]
    env: [string]: string
    source: dagger.#FS
    input?: dagger.#FS

    _forceRun: bash.#RunSimple & {
        script: contents: "true"
        always: true
    }

    _container: #Container & {
        if self.image != _|_ {
            image: self.image
        }

        source: self.source

        command: {
            name: self.name
            args: self.args
        }

        env: self.env & {
            FORCE_RUN_HACK: "\(_forceRun.success)"
        }

        if self.input != _|_ {
            mounts: input: {
                type:     "fs"
                dest:     "/input"
                contents: self.input
            }
        }

        export: directories: "/output": _
    }

    output: _container.export.directories."/output"
}

At the top of this file, you can see the package definition and all our imports. universe.dagger.io is a community repository where we can find pre-made package for Docker, bash, alpine, etc.
Just after that, we start defining our #Command object by adding public fields like command's name, args, custom Docker image (which is optional due to ? character, etc.
We also define our unexported fields (which aren't accessible from outside the package) like the container definition which will run our command (the container object is defined in the container.cue file in the same repository).

This is one of the few definitions that we have in this package, I will not show you directly all of them since it's really specific to our implementation and it's not very relevant to explain how it's working.
However, you can retrieve all of our source code here: https://github.com/camptocamp/dagger-pulumi

So one last file from this pulumi package that we will see is the main.cue one. It's where we defined all the Pulumi commands that we will use (using the #Command object seen just before).

// pulumi/main.cue
[...]
#Preview: self = {
    stack: string
    diff:  bool | *false

    #Command & {
        name: "preview"

        args: [
            "--stack",
            stack,
            "--save-plan",
            "/output/plan.json",

            if diff {
                "--diff"
            },
        ]
    }

    _file: core.#ReadFile & {
        input: self.output
        path:  "plan.json"
    }

    plan: _file.contents
}

#Update: {
    stack: string
    diff:  bool | *false
    plan:  string

    _file: core.#WriteFile & {
        input:    dagger.#Scratch
        path:     "plan.json"
        contents: planHere, you defined 
    }

    #Command & {
        name: "update"

        args: [
            "--stack",
            stack,
                        [...]
            if diff {
                "--diff"
            },

            "--skip-preview",
        ]

        input: _file.output
    }
}
[...]

I voluntary remove some parts of the file and leave only the definition for Pulumi preview and update commands in order to keep it simple.
In the Pulumi context, preview command is used to compare the codebase which defines the desired infrastructure state with the actual one and preview all the potential changes if we apply the configuration.
The update one, as it name says, update the deployed infrastructure to match the desired state.

Using these definitions, we finally defined a #Pulumi object in the main.cue from the parent ci package.
It's composed by few attributes used to set our project environment like, for example, the Pulumi stack (workspace), the env variables, the authorization to run destructive actions through this CI, etc.
We also have a list of all available commands construct using all #Command objects defined earlier.

Finally, the last step before we can be able to run our pipelines is to create the Dagger's plan.
This is the most important part where all jobs are defined but it's really specific to the project for which it's built.
I will present to you a plan from one of our projects where we used the pulumi package that I show you just before.

import (
    "github.com/camptocamp/pulumi-aws-schweizmobil/ci"

    "dagger.io/dagger"
)

dagger.#Plan & {
    client: {
        env: {
            PULUMI_GOMAXPROCS?: string
            PULUMI_GOMEMLIMIT?: string
        }

        filesystem: {
            sources: read: {
                path:     "."
                contents: dagger.#FS

                exclude: [
                    ".*",
                ]
            }

            // TODO
            // Simplify once https://github.com/dagger/dagger/issues/2909 is fixed
            plan: read: {
                path:     "plan.json"
                contents: string
            }

            planWrite: write: {
                path:     "plan.json"
                contents: actions.preview.plan
            }
        }
    }

    #Pulumi: ci.#Pulumi & {
        env: {
            if client.env.PULUMI_GOMAXPROCS != _|_ {
                GOMAXPROCS: client.env.PULUMI_GOMAXPROCS
            }

            if client.env.PULUMI_GOMEMLIMIT != _|_ {
                GOMEMLIMIT: client.env.PULUMI_GOMEMLIMIT
            }
        }

        source: client.filesystem.sources.read.contents
        stack:  string
        diff:   bool
        update: plan: client.filesystem.plan.read.contents
        enableDestructiveActions: bool
    }

    actions: {
        #Pulumi.commands
    }
}

Firstly, you can see at the begin of this file the import of the homemade ci package (as a reminder, it is fully available here)
After, we defined the dagger.#Plan object which is composed by few parts:

the client config: this is where we will be able to set some runtime elements like: env variables, filesystems with read/write permissions, the sources location...
the actions: this is all the possible jobs that you will be able to run using Dagger CLI or in your CI/CD environment, in our case we just use local variable #Pulumi.commands which is built using the #Pulumi object defined in the ci package.

🚀 Launch Dagger's jobs

Locally using CLI

As I told in the previous part of this blog series, Dagger can run any jobs locally thanks to his Dockerize design.
You must have installed the Dagger's CLI for Cue SDK (check the first part of this series or the official documentation if it's not already done).

Once ready, you can open your favorite terminal client located inside your project directory (composed by your Pulumi project and your Dagger plan) and run:

dagger --plan=ci.cue do --with '#Pulumi: stack: "<your_stack>"' preview -> it will run a Pulumi preview on the desired stack
dagger --plan=ci.cue do --with '#Pulumi: stack: "<your_stack>", #Pulumi: diff: true, #Pulumi: enableDestructiveActions: true' update -> it will run a Pulumi update on the desired stack

Remotely using a CI/CD environment

With Dagger you can also run your pipelines on every CI/CD environments!
As a simple example, you can easily run these jobs on Github Actions:

name: pulumi-project

on:
  push:
    branches:
      - main

jobs:
  dagger:
    runs-on: ubuntu-latest
    steps:
      - name: Clone repository
        uses: actions/checkout@v2

      - name: Install Dagger Engine
        run: |
            cd /usr/local
            wget -O - https://dl.dagger.io/dagger/install.sh | sudo sh
            cd -

      - name: Run Pulumi update using Dagger
        run: |
            dagger-cue --plan=ci.cue do update --log-format plain

Note than the --log-format plain flag is useful in order to have well formatted logs in the Github Action output.
With this action, a pulumi update will be launched at every push on the main branch using Dagger.

🔚 Conclusion

If you have made it this far I thank you very much and I hope I have succeeded to give you a good overview of what is Dagger and how is it possible to exploit it in order to improve its practices in terms of CI/CD.

From my point of view, Dagger is a very promising solution. Right now we can still feel Dagger's young age, indeed, it's still not perfect.
In my opinion, each SDK should continue to develop and harmonize with each other. I also think that Dagger's execution performance and cache management should be improved (I'm basing myself on the 0.2 version of the engine since 0.3 is not yet available with the Cuelang SDK so maybe that's already better!).
Nevertheless, the advantages of Dagger are already essential for me, such as the possibility of running its pipelines locally or even being able to run them remotely on a remote VM using local sources.

To be followed very closely! 😉

Use Docker to build better CI/CD pipelines with Dagger

Hugo Bollon — Sun, 11 Dec 2022 05:00:00 +0000

With the raises of DevOps practices, CI/CD (continuous integration & continuous deployment) takes a major place in every delivery workload.
CI/CD allow organizations to build, test and finally ship their applications more quickly and efficiently. It's a modern set of practices which allows to automatically trigger build, test or others types of jobs when the changes to the codebase are done.

In this quest of automation, we can use some CI/CD ecosystem like Github Actions, Gitlab-CI or many more.
However, a very promising new solution open-source is born called Dagger.

🤔 Dagger? What is it?

Dagger.io is a brand-new programmable CI/CD engine which is open-source. It was created by Solomon Hykes, the founder of Docker.
It's designed to use Buildkit from Docker in order to runs our pipelines inside containers.
For those who don't know, Buildkit is an improved backend used by Docker to build images. It's way more efficient than the old legacy Docker's builder due to its improved caching system, the parallelization of build tasks and the support of new features in Dockerfile.

Dagger is also programmable, so we must create our pipelines as code, Dagger himself is written in CUE (Cuelang), a Google's langage.

CUE is an acronym of "Configure Unify Execute" and so as its name suggests, it's not another general purpose language but a declarative one mainly used for data templating and validation, configuration or even code generation.

It's basically an evolution of more lambda languages like YAML or JSON and one of the thing which make it way better and modern is the presence of a package manager.

So going back to Dagger, you can use CUE to build your pipelines but you can also use the SDK available with multiples languages support:

Go
Python
NodeJS

✨ Features and advantages

Dagger, thanks to his innovative containerized design and architecture, leads to many advantages over more conventional CI/CD methods.
As seen previously, Dagger works with Docker containers allowing it to be cross-compatible with every CI/CD runtime environment like Github Actions, Gitlab-CI, Travis-CI, etc.

One of the other main strengths of Dagger is the ability to do local testing of our pipeline using the Dagger CLI. This is made possible by the Dockerized design of it which makes the development and testing processes way easier compared to conventional CI/CD solutions.
Conversely, Dagger is also able to perform remote runs (directly on a self-hosted Github runner for example) with local sources.
To do this it is possible to use the environment variable DOCKER_HOST.

The Dockerized design also allows pipelines made with Dagger devkit to be run in every CI/CD runtime environment like, for example, Github Action (using the official Dagger Github Action from the marketplace).
Furthermore, it can also be run independently of the architecture of the platform. The only requirement is the Docker ecosystem support. So it can be run on a managed runner (eg. Github Runners), a self-hosted runner, a local machine, a serverless compute instance, etc.

Furthermore, Dagger has a solid caching system which caches every operation by default, but it's customizable.
It helps to reduce execution time of CI/CD jobs after the first runs by caching some unchanged required files like: the downloaded dependencies, some built binaries or just some CI/CD engine stuff.

Finally, Dagger is designed to be reusable thanks to his internal package manager (provided by the Cue language). Indeed, it's similar to the one of the language Golang.

package app

import (
    "dagger.io/dagger"
    "dagger.io/dagger/core"
    "universe.dagger.io/bash"
    "universe.dagger.io/docker"
)

Here you can see the import of some packages from the "universe". The Universe is a community package repository, all sources of these packages can be found here, you can also contribute to them.

❓ How does it works?

Dagger is language agnostic, the wish of the team behind is to allow developers to make their pipelines with the language of their choice.
For that, Dagger use a specific architecture. The SDKs (Go, Cue, Node and Python) don't actually run your pipelines themself. Instead, they send pipeline definitions to the Dagger GraphQL API which will after trigger the Dagger Engine.

Dagger's architecture scheme. Ref: https://dagger.io/blog/graphql

🎮 Demo application using Cue SDK

Dagger's team made a demo app with pipelines designed to execute build and test jobs. It's useful to discover and try Dagger.
To use it, you must, of course, have Docker installed since Dagger will use Buildkit but you must also install the CLI (the CUE one is available here: https://docs.dagger.io/sdk/cue/526369/install)
Once done, clone this repository: https://github.com/dagger/todoapp/blob/main/dagger.cue
Finally, open a terminal inside this freshly cloned project and run dagger-cue project update.

Now you're ready to get your hands in Dagger, if you look at the dagger.cue file you will see the plan.
A plan in Dagger orchestrates the Actions. It's the base component of your configuration.

Within this plan we can:

interact with the client filesystem
- read files, usually the current directory as .
- write files, usually the build output as _build
read and define env variables
declare jobs like dependencies update, build & test

There is the one of this demo app:

package todoapp

import (
    "dagger.io/dagger"

    "dagger.io/dagger/core"
    "universe.dagger.io/netlify"
    "universe.dagger.io/yarn"
)

dagger.#Plan & {
    actions: {
        // Load the todoapp source code 
        source: core.#Source & {
            path: "."
            exclude: [
                "node_modules",
                "build",
                "*.cue",
                "*.md",
                ".git",
            ]
        }

        // Build todoapp
        build: yarn.#Script & {
            name:   "build"
            source: actions.source.output
        }

        // Test todoapp
        test: yarn.#Script & {
            name:   "test"
            source: actions.source.output

            // This environment variable disables watch mode
            // in "react-scripts test".
            // We don't set it for all commands, because it causes warnings
            // to be treated as fatal errors.
            // See https://create-react-app.dev/docs/advanced-configuration
            container: env: CI: "true"
        }

        // Deploy todoapp
        deploy: netlify.#Deploy & {
            contents: actions.build.output
            site:     string | *"dagger-todoapp"
        }
    }
}

You can see that three different jobs are defined:

a build one which will compile the react app using yarn
a test one
a deploy one

To execute locally one of those, you can execute: dagger-cue do <job_name>.
So to build the project you can do dagger-cue do build.

⛏️ To go deeper

I hope to have given you a good overview of Dagger with this first chapter or at least to have made you want to go further with it.
Getting started with Dagger and CUE is not necessarily easy.
It's still an extremely young product (we are currently in version v0.2.36) and there is, therefore, still a lot of optimization work to be done as well as missing features.
Keep in mind that Dagger is an open-source project available on Github so don't hesitate to open issues or pull request if needed.

In the next (coming soon) chapter we will see how to use Dagger to build a deployment workflow for a Pulumi project and how to manage secrets.

How I deployed a serverless and high availability Blackbox Exporter on AWS Fargate

Hugo Bollon — Mon, 04 Jul 2022 14:19:14 +0000

At Camptocamp, we're using multiple Blackbox Exporters hosted in a few different cloud providers and world regions. We're using them to monitor availability and ssl certificate validity and expiration of many websites.
They were all deployed inside Linux VMs provisioned by Terraform and configured by our Puppet infrastructure. However, in order to achieve more simplicity and high availability, we wanted to deploy containers instead of these VMs.

🧐 Why a serverless approach with AWS Fargate

AWS ECS (Elastic Container Service) is a fully managed, highly scalable and docker compatible container orchestration service.
It is widely used to host microservice applications like webservers, APIs or machine learning applications.

With ECS, you're free to choose between EC2 or Fargate instances to run your apps.
Fargate is a serverless compute engine which allows you to just focus on building and deploying your apps by taking away all infrastructure deployments and maintenance. No need to worry about security or operating systems, AWS will handle that.
On the other hand, EC2 is more flexible than Fargate and less expensive. It can also be interesting for some customers to manage the security themselves.

In our case, we opted for a serverless approach using Fargate in order to take advantage of the simplicity of a managed infrastructure since for blackboxes we have no specific security constraints for the infrastructure.

🧳 What I use

To deploy an application on ECS using Fargate you will need three different components:

An ECS Cluster
An ECS Task Definition
One or more ECS Service The Task Definition is a template where you define your application (Docker image, ressources requests, networking mode, etc.). The Service is the component that will deploy our Fargate instance(s) based on our task definition(s) in the newly created Cluster.

At Camptocamp, we're doing IAC (infrastructure as code) using mostly Terraform. In order to simplify the deployment of all the resources necessary for the implementation of these components, I created two distinct Terraform modules: one to create an ECS Cluster and one to create Services within an existing cluster.
They have been designed to be flexible and reusable, and we will take a closer look at them to find out what they do and how they work.

⚙️ Module: ECS Cluster

Firstly, I created a module aiming to deploy:

an ECS cluster
an associated VPC
the necessary IAM roles
a Cloudwatch Log Group
network components (internet gateway, subnets, routes)

To use this module, we must provide some inputs variables:

A project name
A project environment (optional)
A list of public subnets
A list of private subnets
A list of availability zones

Link:

camptocamp / terraform-aws-ecs-cluster

Terraform module used to create a new AWS ECS cluster with VPC, IAM roles and networking components

terraform-aws-ecs-cluster

Terraform module used to create a new AWS ECS cluster with VPC, IAM roles and networking components

View on GitHub

⚙️ Module: ECS Service Fargate

Then, this second module aims to deploy a Fargate Service in an existing ECS Cluster (in this case deployed with the previous module).
It will also create everything necessary to be able to access our service. Here is the full list of resources that will be created:

An ECS Fargate Service with its needed Security Group
An ALB (Application Load Balancer) also with a Security Group
A Target Group
An HTTP and HTTPS Listeners
A DNS Zone and Record to the ALB
An ACM Certificate with validation

Once again, this module requires some variables to be used but this time the list is a little bit longer so here are just the most important ones:

An application name
An ECS Cluster ID
An ECS Task Definition ressource (to define what will be deployed on this instance)
A DNS Zone and Host
A VPC's ID and CIDR Blocks
An application port
Public and private subnets ids

Link:

camptocamp / terraform-aws-ecs-service-fargate

Terraform module used to create a new Fargate Service in an existing ECS cluster with networking components (ALB, Target Group, Listener)

terraform-aws-ecs-service-fargate

Terraform module used to create a new Fargate Service in an existing ECS cluster with networking components (ALB, Target Group, Listener)

View on GitHub

🎓 How to

So, our use case is to have a serverless Blackbox Exporter deployed on AWS ECS using a Fargate instance in the eu-west-1 region.
Furthermore, it must be accessible only by https with a valid ssl certificate and with basic authentication.

In order to achieve that, we must add a Nginx sidecar container which will handle basic auth and proxying of the traffic to the Blackbox for authenticated entities.

There is a simple architecture diagram of what we will achieve:

First, we will begin by creating the ECS Cluster using terraform-aws-ecs-cluster module, so, with all nested resources (VPC, subnets, etc.).

# versions.tf

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {
  region     = "eu-west-1"
}

# main.tf

module "ecs-cluster" {
  source = "git@github.com:camptocamp/terraform-aws-ecs-cluster.git"

  project_name        = "ecs-cluster-blackbox-exporters"
  project_environment = "prod"
  availability_zones  = ["eu-west-1a", "eu-west-1b"]
  public_subnets      = ["10.0.0.0/24", "10.0.10.0/24"]
  private_subnets     = ["10.0.20.0/24", "10.0.30.0/24"]
}

As you can see, a minimum of two availability zones is required in order to create VPC subnets. You also need to provide at least two public and two private cidr blocks.

Now that we have declared the module which will create a fresh ECS cluster with all networking stuff associated with it, we can create the Task Definition of our Blackbox application task that we will need after to define the ECS Service.
A Task Definition is a template where we define the containers that we will be executed on our ECS service (docker image to run, port mapping, environments values, log configuration, etc.), the resources required (CPU / Memory), the network mode of the task (with Fargate we must use awsvpc mode), and much more!

So, as we saw earlier, we will need two containers:

A Blackbox-Exporter container which will have port 9115 exposed but inaccessible from the outside of the cluster.
A Nginx container which will be exposed to the internet on port 80 with a basic authentication. It will forward authenticated users to the Blackbox container. We will use this docker image which allows an easy configuration of basic auth using env vars.

We will use the Cloudwatch Log Group created by the ecs-cluster module for the logs of these two containers.
Furthermore, we will also use IAM users created by the module for execution and task role ARNs of our Task Definition.

# main.tf

resource "aws_ecs_task_definition" "blackbox_fargate_task" {
  family   = "blackbox-exporter-task"

  container_definitions = <<DEFINITION
  [
    {
      "name": "ecs-service-blackbox-prod-container",
      "image": "prom/blackbox-exporter:latest",
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "${module.ecs-cluster.cloudwatch_log_group_id}",
          "awslogs-region": "eu-west-1",
          "awslogs-stream-prefix": "ecs-service-blackbox-exporter-prod"
        }
      },
      "portMappings": [
        {
          "containerPort": 9115
        }
      ],
      "cpu": 256,
      "memory": 512
    },
    {
      "name": "ecs-service-nginx-prod-container",
      "image": "beevelop/nginx-basic-auth:v2021.04.1",
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "${module.ecs-cluster.cloudwatch_log_group_id}",
          "awslogs-region": "eu-west-1",
          "awslogs-stream-prefix": "ecs-service-nginx-exporter-prod"
        }
      },
      "environment": [
        {
          "name": "HTPASSWD",
          "value": "${var.blackbox_htpasswd}"
        },
        {
          "name": "FORWARD_HOST",
          "value": "localhost"
        },
        {
          "name": "FORWARD_PORT",
          "value": "9115"
        }
      ],
      "portMappings": [
        {
          "containerPort": 80,
          "hostPort": 80,
          "protocol": "tcp"
        }
      ],
      "networkMode": "awsvpc"
    }
  ]
  DEFINITION

  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  memory                   = "512"
  cpu                      = "256"
  execution_role_arn       = module.ecs-cluster.ecs_task_execution_role_arn
  task_role_arn            = module.ecs-cluster.ecs_task_execution_role_arn

  tags = {
    Name        = "ecs-service-blackbox-exporter-td"
    Environment = "prod"
  }
}

In this exemple, I get the htpasswd from a Terraform variable var.blackbox_htpasswd. You can define it like this:

# variables.tf

variable "blackbox_htpasswd" {
  type = string
  sensitive = true
}

Next, we will need a DNS Zone where the ECS Service module will create the record.

# dns.tf

resource "aws_route53_zone" "alb_dns_zone" {
  name              = "example.com"
  delegation_set_id = "<Delegation_set_id>"
}

Optionally, you can create a delegation set in your AWS account, if you don't already have one, and add a delegation set id on your Route53 zone resource in order to always have the same DNS servers.

Finally, we can now create our ECS Service :

module "ecs-cluster-service-blackbox" {
  source = "git@github.com:camptocamp/terraform-aws-ecs-service-fargate.git"

  app_name        = "ecs-service-blackbox"
  app_environment = "prod"
  dns_zone        = "example.com"
  dns_host        = "blackbox.example.com"

  vpc_id          = module.ecs-cluster.vpc_id
  vpc_cidr_blocks = module.ecs-cluster.vpc_cidr_blocks

  ecs_cluster_id         = module.ecs-cluster.ecs_cluster_id
  task_definition        = aws_ecs_task_definition.blackbox_fargate_task
  task_lb_container_name = "ecs-service-nginx-prod-container"
  task_lb_container_port = 80

  subnet_private_ids = module.ecs-cluster.private_subnets.*.id
  subnet_public_ids  = module.ecs-cluster.public_subnets.*.id

  generate_public_ip = true

  depends_on = [
    aws_route53_zone.alb_dns_zone
  ]
}

As you can see, you must provide to the module some of the previously created resources including: vpc id and cidr_blocks, ECS cluster id, DNS zone, the task definition ressource and the subnets.
You must also set on which container the load balancer will redirect requests and on which port.

Once all your resources are properly configured, you can run a terraform apply to create them.

That's it 🥳! You now have a nice serverless Blackbox accessible on blackbox.example.com with basic auth! 🎉

Introduction to string edit distance and Levenshtein implementation in Golang

Hugo Bollon — Sun, 27 Sep 2020 15:28:35 +0000

In many domains and applications, we are sometimes led to having to compare several words or phrases and quantify their similarity.

A fairly popular notion for this is the edit distance.

Edit distance? What is it?

Edit distance is a metric used to quantify the dissimilarity between two strings by counting the amount of operation needed to transform one to another. Depending on the algorithm chosen, the operations allowed may include: addition, deletion, substitution and finally translation.

This measurement can then be used to calculate a percentage of similarity between two strings with this formula:

(maxLength - distance) / maxLength

Differents types of edit distance

There are many algorithms for calculating edit distance of two distinct strings.

Among them, the most famous are:

Levenstein distance allowing insertion, deletion and substitution. This is the most famous edit distance algorithm but despite what you may think, it is not always the most appropriate.
Damerau-Levenstein distance allowing addition, deletion, substitution and transposition.
There are two different methods of this algorithm, OSA (Optimal string alignment distance) which allows only a transposition by substring and Adjacent Transpositions which allows it as much transposition as necessary but which requires a fixed alphabet.
LCS distance (Longest Common Subsequence) allowing addition and deletion. It's based on Longest Common Subsequence algorithm.
Hamming distance only applicable on strings of the same length, it allows only character substitution.
Jaro distance allowing only transposition and returning a normalized similarity index between 0 and 1.
There is a variant called Jaro-Winkler which takes into account the common prefix of the two strings and which gives it greater weight in the calculation.

The Golang implementation of all of these algorithms with Unicode compatibility are available here :

https://github.com/hbollon/go-edlib

For the rest of this course, we will focus on Levenstein algorithm.

What is it used for?

Edit distance can be used in several application areas such as:

Fuzzy search algorithms
Correction of spelling mistakes
Word completion
DNA sequence alignment algorithms
Pattern matching
And many more!

Levenstein distance

Levensthein is one of the most known edit distance algorithm. It was created by the Soviet mathematician Vladimir Levenshtein, who considered this distance in 1965. It allows insertions, deletions or substitutions.

For example, the Levenshtein distance between “kitten” and “sitting” is 3 since, at a minimum, 3 edits are required to change one into the other.

kitten → sitten (substitution of “s” for “k”)
sitten → sittin (substitution of “i” for “e”)
sittin → sitting (insertion of “g” at the end).

Definition

The Levenshtein distance between two strings is defined by lev a,b(|a|,|b|) with:

a,b : two input strings
|a| : length of a
|b| : length of b

We can find the Levenstein function on Wikipedia

However, it's not easy to understand at first.

Firstly, if one of the input strings is empty then the edit distance is the length of the other.

Else, we will solve the Levenstein algorithm.

In this part, 1(aᵢ≠bⱼ) is equal to 0 when aᵢ≠bⱼ and equal to 1 otherwise. It

aᵢ refers to the character of string a at position i
bⱼ refers to the character of string b at position j

We want to check that these are not equal, because if they are equal, no edit is needed, so we shouldn't add 1 to the edit distance. However, if they aren't equal, we want to add 1 to it.

Algorithm and complexity

There are several implementations of Levenshtein's algorithm, however, not all of them are efficient.
We are going to look after the iterative method with full matrix.

The matrix will contain distance between all prefixes of your input strings, then we can compute the matrix values in a dynamic programming style and finally find the distance between the two full strings as the last value computed.

For exemple, we will have this matrix for kitten and sitting:

As we can see, the edit distance between kitten and sitting is 3.

Pascal algorithm

On Wikipedia, you can find a pseudo-code algorithm of this implementation:

function LevenshteinDistance(char s[1..m], char t[1..n]):
  // for all i and j, d[i,j] will hold the Levenshtein distance between
  // the first i characters of s and the first j characters of t
  declare int d[0..m, 0..n]

  set each element in d to zero

  // source prefixes can be transformed into empty string by
  // dropping all characters
  for i from 1 to m:
      d[i, 0] := i

  // target prefixes can be reached from empty source prefix
  // by inserting every character
  for j from 1 to n:
      d[0, j] := j

  for j from 1 to n:
      for i from 1 to m:
          if s[i] = t[j]:
            substitutionCost := 0
          else:
            substitutionCost := 1

          d[i, j] := minimum(d[i-1, j] + 1,                   // deletion
                             d[i, j-1] + 1,                   // insertion
                             d[i-1, j-1] + substitutionCost)  // substitution

  return d[m, n]

Normally, if you understand what has been said so far, you should roughly understand it. :)

This algorithm has a worst-case complexity of O(n*m), here a quick illustration of that:

Golang implementation

It's all well and good to know all this, but how about implementing it in a real programming language?

For this, we will use Go. It's a modern and compiled language design by Google.

Our implementation will be compatible with Unicode, so you will be able to put emoji or mathematical symbols for example in input strings!

To begin, let's create the function!

func LevenshteinDistance(str1, str2 string) int {

}

It will take two input strings and return an edit distance.
Now, we must convert our strings into rune arrays to be Unicode compatible:

// Convert string parameters to rune arrays to be compatible with non-ASCII
runeStr1 := []rune(str1)
runeStr2 := []rune(str2)

In Go, a rune is an alias for int32 (32-bit integer).

Once that is done, we need to retrieve the length of these strings and start looking if these strings are equal or if any of them is empty.

// Get and store length of these strings
runeStr1len := len(runeStr1)
runeStr2len := len(runeStr2)
if runeStr1len == 0 {
    return runeStr2len
} else if runeStr2len == 0 {
    return runeStr1len
} else if utils.Equal(runeStr1, runeStr2) {
    return 0
}

utils.Equal is a utility function that I have defined to check equality of two rune arrays, you can retrieve it here. Alternatively, you can compare directly strings input.

To be more simple, our implementation will use a simple slice instead of a matrix, but the principle is the same.

Let's create our distance array and initialize it:

// The slice size must be of the length of "runeStr1len+1"
column := make([]int, runeStr1len+1)
for y := 1; y <= runeStr1len; y++ {
    column[y] = y
}

Finally, let's compute the column array with the Levenstein algorithm and return the distance between our input strings:

for x := 1; x <= runeStr2len; x++ {
    column[0] = x
    lastkey := x - 1
    for y := 1; y <= runeStr1len; y++ {
        oldkey := column[y]
        var i int
        if runeStr1[y-1] != runeStr2[x-1] {
            i = 1
        }
        column[y] = utils.Min(
            utils.Min(column[y]+1, // insert
                column[y-1]+1), // delete
            lastkey+i) // substitution
        lastkey = oldkey
    }
}

return column[runeStr1len]

utils.Min, like previously, is a custom function, you can retrieve it here.

That's it! Now you can compute the Levenstein distance between any words or sentences that you want!

If you haven't made any mistakes, you should have this:

// LevenshteinDistance calculate the distance between two string
// This algorithm allow insertions, deletions and substitutions to change one string to the second
// Compatible with non-ASCII characters
func LevenshteinDistance(str1, str2 string) int {
    // Convert string parameters to rune arrays to be compatible with non-ASCII
    runeStr1 := []rune(str1)
    runeStr2 := []rune(str2)

    // Get and store length of these strings
    runeStr1len := len(runeStr1)
    runeStr2len := len(runeStr2)
    if runeStr1len == 0 {
        return runeStr2len
    } else if runeStr2len == 0 {
        return runeStr1len
    } else if equal(runeStr1, runeStr2) {
        return 0
    }

    column := make([]int, runeStr1len+1)

    for y := 1; y <= runeStr1len; y++ {
        column[y] = y
    }
    for x := 1; x <= runeStr2len; x++ {
        column[0] = x
        lastkey := x - 1
        for y := 1; y <= runeStr1len; y++ {
            oldkey := column[y]
            var i int
            if runeStr1[y-1] != runeStr2[x-1] {
                i = 1
            }
            column[y] = min(
                min(column[y]+1, // insert
                    column[y-1]+1), // delete
                lastkey+i) // substitution
            lastkey = oldkey
        }
    }

    return column[runeStr1len]
}

// Return the smallest integer among the two in parameters
func min(a int, b int) int {
    if b < a {
        return b
    }
    return a
}

// Compare two rune arrays and return if they are equals or not
func equal(a, b []rune) bool {
    if len(a) != len(b) {
        return false
    }
    for i, v := range a {
        if v != b[i] {
            return false
        }
    }
    return true
}

I sincerely hope you enjoyed this course and that it is not too messy! As a french student, this my first stories attempt so any feedback are welcome! :)

I've done an edit distance and string comparison open-source library: Go-Edlib.
It implements most popular edit distance algorithms and soon all of them! Currently, it includes: Levenshtein, LCS, Hamming, Damerau-Levenshtein (OSA and Adjacent transpositions algorithms), Jaro/Jaro-Winkler.
All these algorithms have been implemented in such a way as to be fully compatible with Unicode

It also includes fuzzy search algorithms based on edit distance and few others string comparisons functions.

I'm actively looking for feedback and/or contributions to improve this library or have new functionality ideas to add!

I created Golang edit distance & string comparison library : Go-Edlib

Hugo Bollon — Sat, 19 Sep 2020 14:50:31 +0000

Edit Distance?

Edit Distance is a metric used to quantify the dissimilarity between two strings by counting the amount of operation needed to transform one to another. Depending on the algorithm chosen, the operations allowed may include: addition, deletion, substitution and finally translation.

This measurement can then be used to calculate a percentage of similarity between two strings with this formula:

(maxLength - distance) / maxLength

To illustrate this, we will look at the Levenshtein algorithm. Levensthein is one of the most known edit distance algorithm. It was created by the Soviet mathematician Vladimir Levenshtein, who considered this distance in 1965. It allows insertions, deletions or substitutions.

For example, the Levenshtein distance between “kitten” and “sitting” is 3 since, at a minimum, 3 edits are required to change one into the other.

kitten → sitten (substitution of “s” for “k”)
sitten → sittin (substitution of “i” for “e”)
sittin → sitting (insertion of “g” at the end).

What is it used for?

Edit distance can be used in several application areas such as:

Fuzzy search algorithms
Correction of spelling mistakes
Word completion
DNA sequence alignment algorithms
Pattern matching
And many more!

So what is go-edlib?

Go-Edlib is a new open-source library for Golang that implements most popular edit distance algorithms and soon all of them! Currently, it includes: Levenshtein, LCS, Hamming, Damerau-Levenshtein (OSA and Adjacent transpositions algorithms), Jaro/Jaro-Winkler.
All these algorithms have been implemented in such a way as to be fully compatible with Unicode

It also includes fuzzy search algorithms based on edit distance and few others string comparisons functions.

Link: https://github.com/hbollon/go-edlib

I'm actively looking for feedback and/or contributions to improve this library or to have new functionality ideas to add! :)
PS: I would also like, if possible, opinions on the quality of my documentation and possibly points to improve