DEV Community: Quartz Technology

RETHV - Building Reth for the RISC-V platform

Quartz Technology — Fri, 28 Jun 2024 16:41:18 +0000

We describe how we managed to run Reth, the Rust Ethereum execution client maintained by Paradigm and the open-source community, on a RISC-V environnement.

As we faced issues and learned many things, we wanted not only to share the finished PoC but also the journey itself. If you'd like to chat about running Reth on RISC-V in more details, feel free to contact us.

Last but not least, we are not experts on the topics described in the document - we might have missed easy fixes, misunderstood concepts or over-engineered some solutions, we encourage you to let us know.

Happy reading!

Introduction
The RISC-V environnement
- Bare Metal
- QEMU to the rescue
Cross-Compiling Reth
Cross-Compilation Target
MDBX Bindgen Configuration
Building Reth
Wrapping Up
- Custom Docker image for RISC-V toolchain
- Using the non-trivial approach
- Using a simpler approach
Running Reth
Conclusion
Acknowledgments
Resources
Authors

Introduction

Our goal was to be able to run Reth on a RISC-V GNU Linux. Why? Because:

We believe it enhances client diversity. It's not only about what is the most used client implementation, but also what hardware it runs on.
It's an amazing challenge. We learned many things about cross-compilation, QEMU and the tools used in Reth.
Extending the previous reason, we just wanted to share our journey with the community. Maybe it'll help some of you get started on RISC-V, exploring QEMU and more.

We'll explain how we managed to configure a RISC-V environnement, how we cross-compiled Reth for the RISC-V target and present the tools used to achieve it. We'll also recap the limitations we currently know about.

The RISC-V environnement

In this first section, we describe how we failed to run Reth on a non-compatible bare-metal environnement, which led us to use a VM with the help of QEMU.

Bare Metal

At the beginning, we really wanted to run Reth on a bare-metal server with a RISC-V processor.

We used the Elastic Metal RV1 instances from Scaleway but faced a first error we previously encountered when trying to run Reth on ARM64 machines: the virtual memory layout on Linux.
In a nutshell, the Linux kernel can be compiled to use a specific virtual memory layout, but the hardware on the machine might not support all of them.
Scaleway's instances only support SV39 mode at best, while we need SV48 at least. Not using a proper virtual memory layout leads to an error which was documented in the Reth issue here .
On RISC-V Linux, the SV39 mode allows up to 256 GB of user-space virtual memory while the SV48 allows up to 128 TB - as specified in the kernel documentation.
Check-out the issue linked above to learn more about the underlying reasons of why this is an issue for Reth, onbjerg did an amazing job explaining it in simple terms.

When we started the project, Scaleway was the only cloud provider with RISC-V instances and we did not have a dev board at home, which led us to look for another setup: using QEMU to create a RISC-V VM.

QEMU to the rescue

We tried to follow the official documentation for running Linux on QEMU for RISC-V but faced too many compilation errors on macOS with Apple Silicon.

As we had a Ubuntu machine with an x86 CPU on Hetzner for development purposes, we decided to immediately switch.
After following the instructions to compile QEMU with RISC-V compatibility and running a compatible Debian image (amazing blog post with the instructions here), it worked!
You can connect to the VM using:

ssh root@localhost -p 2222 # Passord: root

root@debian:~# uname -r
6.8.12-riscv64
root@debian:~# cat /proc/cpuinfo
...
mmu             : sv57 # Sweet, this virtual memory layout allows up to 64 PB user-space virtual memory. Enough to store da blobs.
...

Note that the provided image only has a 10 GB-size disk. If you'd like to extend it consider taking a look at this SO answer and then resizing the FS using fdisk (be careful, when expanding the root partition, the first sector might not be the default one) and resize2fs.

The development environnement is ready. Now is the time to build and run Reth.

Cross-Compiling Reth

To compile Reth for the RISC-V 64 target, we have different options:

Compile natively inside the VM. Slow but less prone to errors and requires less configuration tweaks.
Compile using the cross-compiler. Requires to setup the tools first but leads to way faster compilation time.

The first option is actually really easy: just follow the official documentation to build Reth from source from within the VM.
The second option is a bit more complex: we can either use install the cross-compiler from a package manager or build it from source.

As your distribution may very from our own, we chose to build it from the official toolchain sources. In fact, we built a Docker image which contains the RISC-V toolchain built from source for both the amd64 and arm64 platforms.

From there, it's as easy as just running cargo build right? Well, there are two details.
The cross-compilation target must be specified and requires some extra parameters, and the MDBX auto-generated bindings requires extra-configuration.

Cross-Compilation Target

When cross-compiling in Rust using cargo, the target can be specified using the --target flag.
Here, we will inform cargo that the target is riscv64gc-unknown-linux-gnu.
One thing we discovered was that another target we aimed for, riscv64gc-unknown-none-elf, is not yet fully supported by Rust. Namely, it does not support std right now and therefore Reth cannot be cross-compiled for this target.

During the cross-compilation, the linker also must be specified manually, and we chose the easiest way (an environnement variable) to do so:

export CARGO_TARGET_RISCV64GC_UNKNOWN_LINUX_GNU_LINKER=riscv64-unknown-linux-gnu-gcc

But if we try to build Reth, the compilation will fail due to the custom mdbx-sys crate build process.

...
33.85 error: failed to run custom build command for `reth-mdbx-sys v1.0.0 (/build/crates/storage/libmdbx-rs/mdbx-sys)`
33.85
33.85 Caused by:
33.85   process didn't exit successfully: `/build/target/release/build/reth-mdbx-sys-c89ac4f3243e36e2/build-script-build` (exit status: 101)
33.85   --- stdout
33.85   cargo:rerun-if-changed=/build/crates/storage/libmdbx-rs/mdbx-sys/libmdbx
33.85
33.85   --- stderr
33.85   /build/crates/storage/libmdbx-rs/mdbx-sys/libmdbx/mdbx.h:80:2: warning: "The RISC-V architecture is intentionally insecure by design.   Please delete this admonition at your own risk,   if you make such decision informed and consciously.   Refer to https://clck.ru/32d9xH for more information." [-W#warnings]
33.85   /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
...

Let's fix it by tweaking the bindgen configuration.

MDBX Bindgen Configuration

To build the mdbx-sys crate bindings, the bindgen tool is used. As it uses clang to generate the C/C++/Rust bindings, it does not know about the RISC-V toolchain and we must specify it manually.
Hopefully, as stated in the bindgen's README, we can pass extra flags to clang using the BINDGEN_EXTRA_CLANG_ARGS environnement variables (we could also tweak the build.rs file in the crate, but we did not wanted to temper with the sources).

# The sysroot for the quartztech/riscv-gnu-toolchain image is in /usr/local/
export BINDGEN_EXTRA_CLANG_ARGS="--sysroot=/usr/local/sysroot"

Finally, we can build Reth.

Building Reth

Here's the command to build reth using our RISC-V cross-compiler:

cargo build --release --target riscv64gc-unknown-linux-gnu

Wrapping Up

Custom Docker image for RISC-V toolchain

Here's our Dockerfile used as the based image in the next sub-section.
It contains the RISC-V toolchain built from source.

FROM ubuntu:22.04 AS builder

WORKDIR /build

RUN apt-get update && apt-get install -y \
    autoconf \
    automake \
    autotools-dev \
    curl \
    python3 \
    python3-pip \
    libmpc-dev \
    libmpfr-dev \
    libgmp-dev \
    gawk \
    build-essential \
    bison \
    flex \
    texinfo \
    gperf \
    libtool \
    patchutils \
    bc \
    zlib1g-dev \
    libexpat-dev \
    ninja-build \
    git \
    cmake \
    libglib2.0-dev \
    libslirp-dev

RUN git clone https://github.com/riscv/riscv-gnu-toolchain .

# Newlib installation.
RUN ./configure --enable-multilib
RUN make

# Linux installation.
RUN ./configure --enable-multilib
RUN make linux

FROM ubuntu:22.04 AS runtime

WORKDIR /

COPY --from=builder /usr/local /usr/local

ENTRYPOINT [ "/bin/bash" ]

Using the non-trivial approach

For the braves, here's a Dockerfile which uses the Quartz base image to cross-compile Reth:

FROM quartztech/riscv-gnu-toolchain:latest

WORKDIR /build

ENV PATH=/opt/riscv/bin:$PATH

RUN apt-get update && apt-get install -y \
    curl \
    build-essential \
    git \
    pkg-config \
    libssl-dev \
    libclang-dev

RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
ENV PATH=/root/.cargo/bin:$PATH

RUN rustup target add riscv64gc-unknown-linux-gnu

RUN git clone https://github.com/paradigmxyz/reth .

ENV CARGO_TARGET_RISCV64GC_UNKNOWN_LINUX_GNU_LINKER=riscv64-unknown-linux-gnu-gcc
ENV BINDGEN_EXTRA_CLANG_ARGS="--sysroot=/usr/local/sysroot"

RUN cargo build --release --target riscv64gc-unknown-linux-gnu

ENTRYPOINT [ "/bin/bash" ]

Using a simpler approach

Now if you use a simpler method and just install the toolchain from a package manager, here's what the Dockerfile would look like (with Ubuntu as the base image at least):

FROM ubuntu:22.04

WORKDIR /build

RUN apt-get update && apt-get install -y \
    curl \
    build-essential \
    git \
    pkg-config \
    libssl-dev \
    libclang-dev \
    # All of this article for this change ^^, I love reinventing the wheel.
    gcc-riscv64-linux-gnu

RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
ENV PATH=/root/.cargo/bin:$PATH

RUN rustup target add riscv64gc-unknown-linux-gnu

RUN git clone https://github.com/paradigmxyz/reth .

ENV CARGO_TARGET_RISCV64GC_UNKNOWN_LINUX_GNU_LINKER=riscv64-linux-gnu-gcc

RUN cargo build --release --target riscv64gc-unknown-linux-gnu

ENTRYPOINT [ "/bin/bash" ]

Way simpler than everything else, sometimes it's all about installing one package that does the job.

Running Reth

The last step is to copy the binary built inside the Docker image to the RISC-V VM:

docker cp <containerId>:/build/target/riscv64gc-unknown-linux-gnu/release/reth .
scp -P 2222 reth root@localhost:/tmp
ssh root@localhost -p 2222
# ...
# ...
# ...
root@debian:~# cd /tmp
root@debian:/tmp# ls
reth
root@debian:/tmp# ./reth node --full
2024-06-24T20:00:40.554366Z  INFO Initialized tracing, debug log directory: /root/.cache/reth/logs/mainnet
2024-06-24T20:00:40.588379Z  INFO Starting reth version="1.0.0-dev (81b5fbf57)"
2024-06-24T20:00:40.592833Z  INFO Opening database path="/root/.local/share/reth/mainnet/db"
2024-06-24T20:00:40.824511Z  INFO Configuration loaded path="/root/.local/share/reth/mainnet/reth.toml"
2024-06-24T20:00:40.908347Z  INFO Verifying storage consistency.
2024-06-24T20:00:41.025506Z  INFO Database opened
2024-06-24T20:00:41.029405Z  INFO
# ...

While it is definitely NOT an environnement suited for production, it works!

Conclusion

We managed to overcome some challenges to build and run Reth on RISC-V, which contributes to maximizing the diversity of the Ethereum infrastructure!

Now let's not celebrate too much: RISC-V is VERY early, slow and insecure (even MDBX reminds us of this, look back at the logs ^^). It's just a proof of concept and also a good excuse for us to test new things.
We also did not (but it's in the TODO list) synchronized a full-node entirely, and therefore can not attest that it works completely.

I really encourage you to try this on your own, hopefully you'll learn a few things in the process. I spent some time reading documentation on RISC-V, the Rust bindgen, cross-compilation and many more. As everyone has it's own way of approaching this deep-focus phase, I'll let you invest your time as you wish.

Acknowledgments

All the Reth contributors for their amazing work.
Onbjerg for his help on debugging compilation errors on ARM64 due to memory layout configuration.
Colin Atkinson for his post on running RISC-V in QEMU.

Resources

Authors

This project was made by the 🦀 at Quartz Technology.

Setup an Ethereum archive node using Reth on the Orange Pi 5

Quartz Technology — Thu, 20 Jul 2023 16:41:49 +0000

In this post we will prepare a custom version of Armbian for the Orange Pi 5, prepare the board's storage and run the Reth Ethereum execution client in archive mode.

Context

As the newest Ethereum execution client Reth was released, we wanted to share the instructions required to setup your own archive node at home using the Orange Pi 5 board.

We spent some time figuring out the solution to an issue which prevented the node from running correctly due to the way the Linux distributions for this specific board were configured.

For those of you who are curious, the issue itself is documented here.

In the next sections, we describe what is the required hardware to get the node ready, as well as what change will be made to Linux and how to deploy the archive node.

Prepare the hardware

To be able to recompile Armbian (the why is explained in the next section) we need to follow the official documentation requirements.
On our side, we used a Thinkpad running Pop OS.

The modified version of the OS needs to be written to an SD card.
On our side, we used a SanDisk Extreme Pro microSDXC 128 GB.

We also need to connect the board to the local network via the ethernet port and to the power using its USB-C port.

In order to store the data of the archive node, we need external SSDs.
On our side, and despite the fact that this is probably not the most optimised solution, we used two NVMe with 2 TB of storage each, connected to the board using a USB Hub.

Prepare the OS

As briefly mentioned in the first section, we faced an issue the first time we tried to setup the archive node.
MDBX could not set the database size due to the page size being set to 4 KB, restricting the address space to be 512 GB maximum.

So the next question is: How can we change this page size to be bigger ? 🤔
And the answer is: When compiling the Kernel. 😶

Thankfully, Armbian provides an excellent and easy-to-use framework to build the distribution and customise the Kernel features - including the page size.

Let's get started:

On the host machine, plug the micro SD card. Make sure that it is accessible by running the following command:



lsblk

You should see something like this:



NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda               8:0    1 119.1G  0 disk  
└─sda1            8:1    1 119.1G  0 part  /media/xpanoramix/3137-6438
...

Then, clone the Armbian build framework:



git clone https://github.com/armbian/build
cd build

Finally, compile the Linux Kernel for the Orange Pi 5 and flash it to the micro SD card:



./compile.sh \
BOARD=orangepi5 \
BUILD_MINIMAL=yes \
BUILD_DESKTOP=no \
KERNEL_CONFIGURE=yes \
CARD_DEVICE="/dev/sdX" # Replace "sdX" with the one for your micro SD card !

Follow the instructions given in the terminal.
Then, you should see the following screen:

Select the only one and let the process continue. After a while, you should see the following screen appear. Select the "jammy" option:

Let the process continue again, until the following screen appears. Scroll down to "Kernel Features", press Enter and change the page size from "4 KB" to "64 KB".

Save the configuration and load it.

Finally, click on the "Exit" button in the bottom-left and "yes" on the pop-up window that appears right after.

From here, we have to wait for a bit of time until the distribution has been compiled.

At the end, the Armbian image will be flashed to the device specified when running the first command.

Remove it from the host machine, put it into the Orange Pi 5 board and connect power to it.

It is now time to configure the archive node.

Prepare the archive node

In this section, we will do the following things:

Configure the SSDs
Setup Reth
Start the archive node

First and foremost, we need to connect to the board.
You can either use a keyboard + monitor combo or connect using SSH. No matter which solution you decide to use, you'll be forced to choose a new password and create a default user. Just follow those instructions, no need for detailed explanations on this here.

Assuming that we have connected the SSDs to the board, running the lsblk command should print something similar to this:



NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0   1.8T  0 disk
sdb           8:16   0   1.8T  0 disk
mtdblock0    31:0    0    16M  0 disk
mmcblk1     179:0    0 119.1G  0 disk
├─mmcblk1p1 179:1    0   256M  0 part /boot
└─mmcblk1p2 179:2    0 117.6G  0 part /var/log.hdd
                                      /
zram0       254:0    0   7.8G  0 disk [SWAP]
zram1       254:1    0    50M  0 disk /var/log
nvme0n1     259:0    0 119.2G  0 disk

Where you can clearly see my two large NVMes at the top.

We will use lvm to "combine" our disks into one.

You can install the lvm2 tool using the following command:



apt install lvm2 -y

Once installed, you should be able to create the physical volumes using the pvcreate command:



pvcreate /dev/sda /dev/sdb

Then, running the pvdisplay command should print something similar to this:



  "/dev/sda" is a new physical volume of "<1.82 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/sda
  VG Name
  PV Size               <1.82 TiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               Yx27XD-zoGA-USBi-oHZI-zAmh-tKpe-qLDoar

  "/dev/sdb" is a new physical volume of "<1.82 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/sdb
  VG Name
  PV Size               <1.82 TiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               ws3Poe-PE0t-fyQX-l7QT-ncWE-Ym2K-dTdCTg

Then, we need to create a volume group called vg0 using the vgcreate command:



vgcreate vg0 /dev/sda /dev/sdb

Again, we can confirm that the volume group was created using the vgdisplay command:



  --- Volume group ---
  VG Name               vg0
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               <3.64 TiB
  PE Size               4.00 MiB
  Total PE              953864
  Alloc PE / Size       953864 / <3.64 TiB
  Free  PE / Size       0 / 0
  VG UUID               UE9Q3j-2TFe-BvNp-c65E-FCtY-onxA-Rwf40a

Almost done with the volumes ! We need to create and format the logical volume called reth-data using the lvcreate and mkfs.ext4 commands.



lvcreate -n reth-data -l 100%FREE vg0

(Just running the lvdisplay command to confirm that everything went well)



  --- Logical volume ---
  LV Path                /dev/vg0/reth-data
  LV Name                reth-data
  VG Name                vg0
  LV UUID                0Eb4Hk-jMfH-xrtl-vIPP-rRYy-FksS-5igxBj
  LV Write Access        read/write
  LV Creation host, time orangepi5, 2023-07-12 12:22:23 +0000
  LV Status              available
  # open                 0
  LV Size                <3.64 TiB
  Current LE             953864
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0



mkfs.ext4 /dev/vg0/reth-data

Now we just have to mount the volume and make sure that it will be mounted every time the board starts.

To do that, we need to edit the /etc/fstab file and add the following line at the end of it. Note that you can use nano /etc/fstab to make the edit if you don't want to be stuck until the end of time in vim:



/dev/vg0/reth-data /mnt/reth-data ext4 defaults 0 1

This will mount the LVM volume at /mnt/reth-data, but this location does not exist yet, so we need to create it using the mkdir command:



mkdir /mnt/reth-data

Before we jump into deploying Reth, we just need to reboot the system using:



sudo reboot

Connect back to the board, and move into the /mnt/reth-data folder. The available space should be huge - you can check this using the df -h . command.



cd /mnt/reth-data/



Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-reth--data  3.6T   28K  3.4T   1% /mnt/reth-data

Now is the time to deploy Reth and the monitoring stack.
We will use Docker to run everything inside multiple containers. To install the tool, please refer to the official documentation available here.

Once this is done, we can clone the Reth repository:



git clone https://github.com/paradigmxyz/reth.git
cd reth

It is recommended to switch to the latest release:



git checkout v0.1.0-alpha.3 # Replace this with the latest release tag.

And change a few things in the Dockerfile:

First, the BUILD_PROFILE. ```Dockerfile

ARG BUILD_PROFILE=maxperf

...

Copy reth over from the build stage

COPY --from=builder /app/target/maxperf/reth /usr/local/bin


- Then, we can add some Rust flags to enable CPU-specific optimisations: 
```Dockerfile


# Builds dependencies
RUN RUSTFLAGS="-C target-cpu=native" cargo chef cook --profile $BUILD_PROFILE --recipe-path recipe.json

# Build application
COPY . .
RUN RUSTFLAGS="-C target-cpu=native" cargo build --profile $BUILD_PROFILE --locked --bin reth

Finally, expose a new port 8551: ```Dockerfile

EXPOSE 30303 30303/udp 9001 8545 8546 8551


And this is it for the changes.

Now copy and paste the following content into a new `docker-compose.yaml` file in the parent directory (`/mnt/reth-data`):

```yaml


version: "3"

services:
  reth:
    restart: always
    build:
      context: ./reth
      dockerfile: Dockerfile
    networks:
      - reth-net
    ports:
      - "30303:30303"
      - "30303:30303/udp"
      - "9001:9001"
      - "8545:8545"
      - "8546:8546"
      - "8551:8551"
    volumes:
      - ./datadir:/app/datadir/
    command: ["node", "--datadir", "/app/datadir/", "--authrpc.addr", "0.0.0.0", "--http", "--http.addr", "0.0.0.0", "--metrics", "0.0.0.0:9001"]

  lighthouse:
    restart: always
    image: sigp/lighthouse:latest
    networks:
      - reth-net
    volumes:
      - ./datadir:/app/datadir/
    command:
      - "lighthouse"
      - "bn"
      - "--checkpoint-sync-url"
      - "https://mainnet.checkpoint.sigp.io"
      - "--execution-endpoint"
      - "http://reth:8551"
      - "--execution-jwt"
      - "/app/datadir/jwt.hex"

networks:
  reth-net:

volumes:
  datadir:

This configuration combine both Reth (the execution client) and lighthouse (the consensus client).
You can start the containers using the following command:



docker compose up -d

And you should see the building process starting. Be patient, this can take a while because we are building the most optimised binary possible of Reth.

Additionally, you can setup a monitoring stack by following the instructions from the official Reth documentation available here.

And voilà ! Once the node is synced (which should take a few days) we will be able to play with it ! In the meantime, there's nothing better than observing the sync process:

Conclusion

In this post, we prepared our own Ethereum archive node, from building the OS with specific features enabled up until we installed and deployed the Reth execution client.

I would like to personally thank onbjerg for his help on resolving the issue caused by the incorrect page size. He actually was the one who indirectly made Reth work on the Orange Pi 5 !

Of course, we also want to say thank you to all the Reth contributors ❤️

We hope this helped ! Feel free to reach us out or comment if you have any question 🚀

Written by 0xpanoramix - Luca G.F. for Quartz.

Use reusable workflows to push images on GitHub Actions

Quartz Technology — Mon, 19 Jun 2023 14:08:09 +0000

Most applications are composed of many services, and it may lead to hundreds or thousands of GitHub actions lines to manage everything.

This post explains how reusable workflows and matrix can reduce GitHub actions yaml to only few lines without any duplications.

Context

Let's begin with a bit of context to understand why and when the usage of reusable workflows can be useful.

Here's a list of exhaustive reasons:

You have some duplications in your actions, for instance when you want to build and push your application's services on a registry (like Docker Hub, GitHub registry...)
You identify common pattern, setup or steps in your CI, this could be setup step or whole processes where the only difference can be abstract with variables. For instance, you have same steps but in different directories.
You are working on a project with a lot of services that need to be tested, packaged and deployed online.

If you can recognize one of your project, this blog post is written for you!

For this project, I will use a real case that I met for one of my client: Pridwen. This project is a financial tool composed of multiple services, some are fetching data, there is 2 REST API, a Websocket services, telegrams bots and also additional utilities processes for backup, observabilities, update and analysis.

In total, there are 10 Python services that need to be packaged, so it can be deployed on an VPS.
All these services have common deployment processes, they are packaged into Docker images and then ran as services through a docker compose.

As well, before doing a release in production, changes are deployed in a development environment. Which means images are built many times and with different tags depending on the stage.

The schema below shows the development and production release process. Each push on master updates the development stage and there is a manual workflow to release the stack in production.

Indeed, each service has its own Dockerfile, since all services share common dependencies, these Dockerfile are located at the root of the repository as shown below:



ls | grep ".Dockerfile"
# auto_quoter.Dockerfile
# backend.Dockerfile
# eod_price_update.Dockerfile
# eod_price_update_manual.Dockerfile
# eow_performance.Dockerfile
# expiry_checker.Dockerfile
# rfq_rest.Dockerfile
# rfq_ws_api.Dockerfile
# telegram_quote.Dockerfile
# telegram_rfq_broadcaster_derivatives.Dockerfile
# telegram_rfq_broadcaster_spot.Dockerfile

All those processes could lead to thousands of YAML lines, which would be so painful to write and maintain.
But GitHub shipped a recent feature to fix this issue: reusable workflows.

Create a reusable workflow

The main pain point in the project was to build and push image to a registry.

The common action is the following:



jobs:
  build_publish:
    name: Build and publish image
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository.
        uses: actions/checkout@v3

      - name: "Setup Docker Buildx"
        uses: docker/setup-buildx-action@v1

      - name: "Login to Registry"
        uses: docker/login-action@v2
        with:
          registry: <registry>
          username: <username>
          password: <password> # Stored as secret in GH environment

      - name: Build & push image
        uses: docker/build-push-action@v4
        with:
          context: <context of the build>
          file: <dockerfile path>
          push: true
          tags: |
            <registry address>/<repo>/<service_name>:<version tag>

As you see, this is a lot of steps, which are basically the same no matter the service nor the language. You just need to pick up the write context and Dockerfile to push it to a registry.

This is a typical situation where a reusable workflow could be useful.
Before writing it, let's identify which values are dynamic and shall be abstract as variable:

The context of the build, you may have your Dockerfile into different folders. Or for clarity purpose, you may want to explicitly set the context.
The Dockerfile path, indeed because you may have multiple Dockerfile in your path, or you simplify named them differently than Dockerfile.
The service name in the tag, because you want to push each services with a different image name.
The version tag, since you may want to push dev, latest or specific versions like v1.0.0.

⚠️ Unfortunately, reusable workflows cannot access GitHub environment or secrets, so we also need to add an extra variable to forward the registry password to the workflow.

We know our common steps and dynamic variable, let's create this reusable workflow.

Let's create a new file build-push-image-reusable-workflow.yml.



# Go into workflows directory
cd .github/workflows

# Create new file
touch build-push-image-reusable-workflow.yml

Then let's write the workflow:



# No name since it is not an Action by itself.

on:
  # Special GitHub trigger to specify a reusable workflow
  workflow_call:
    # Define secrets into secrets key
    secrets:
      REGISTRY_TOKEN:  # Define REGISTRY_TOKEN variable
        required: true # Set as required

    # Define classic input (not hidden in CI)
    inputs:        
      app:                              # Define app variable
        type: string                    # Set type as string
        description: Application name   # Set description
        required: true                  # Set as required

      tag:
        type: string
        description: Tag to give to the built image
        required: true

      context:
        type: string
        description: Context to use on the build
        required: false                           # Set as optional
        default: '.'                              # Set default value to .

      dockerfile:
        type: string
        description: Dockerfile to use to built the image
        required: false
        default: 'Dockerfile'

# Define reusable job
jobs:
  build_publish:
    name: Build and publish image # Specify job's name
    runs-on: ubuntu-latest        # Run on Ubuntu runner

    steps:
      - name: Checkout repository.
        uses: actions/checkout@v3

      - name: "Setup Docker Buildx"
        uses: docker/setup-buildx-action@v1

      - name: "Login to GitHub Registry"
        uses: docker/login-action@v2
        with:
          registry: <registry address>
          username: <username>
          password: ${{ secrets.REGISTRY_TOKEN }} # Use secret arguments through secrets.<variable name>

      - name: Build & Push image
        uses: docker/build-push-action@v4
        with:
          context: ${{ inputs.context }} # Use input as inputs.<variable names>
          file: ${{ inputs.dockerfile }}
          push: true
          tags: |
            <registry address>/<repository>/${{ inputs.app }}:${{ inputs.tag }}

The reusable workflow is ready, let's use it with a matrix!

💡To get more information about reusable workflows capabilities, have a look at the official documentation.

Use the workflow with matrix

First, what is a GitHub action matrix and why using it?

The matrix is a special field in the GitHub Action that will define different values that will then be inserted into a same job so GitHub can execute them in parallel. This is useful to gain time but also avoid duplication, specially in combination with reusable workflow.

To make the usage of matrix possible, I reduced the number of dynamic variable to the minimum. In our case, only the name of the Dockerfile may be set.

Let's write a file to push images in development stage.



# Create new file
touch dev_cd.yml

And inserts the following content to build and push our 10 services.



name: Build and push services to registry in dev stage.

on:
  push:
    branches: [master] # Update dev on push on main

jobs:
  build-push-services:
    strategy:
      matrix:
        # Create service key with list of each service.
        service: 
        - backend
        - rfq_rest
        - rfq_ws_api
        - telegram_quote
        - telegram_rfq_broadcaster_derivatives
        - telegram_rfq_broadcaster_spot
        - auto_quoter
        - expiry_checker
        - eod_price_update
        - eow_performance
    name: Build ${{ matrix.service }} # Name workflow with the service processed.
    # Select the reusable workflow directly in your GH repository
    # You may update the @main to any branch you want to test the workflow
    # and then update it to main after merge.
    uses: <gh organisation>/<repository>/.github/workflows/build-publish-workflows.yml@main
    # Forward secret using secrets field.
    secrets:
      REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
    # Set input using with field
    with:
      app: ${{ matrix.service }}                   # Service built
      tag: dev                                     # Set image tag as dev
      dockerfile: ${{ matrix.service }}.Dockerfile # Dockerfile to use

Here is an example of the action running on Pridwen. You might get similar update with more or less services.

I hope this article was useful! As a DevOps, it's always painful to see complex and mystic CI/CD, I wish this article showed another way to do things to have easy and efficient processes.

Feel free to reach me out or comment if you have any question 🚀

❤️ Thanks again to Pridwen for letting me use its use-case as example.

Written by Vasek - Tom C. for Quartz.

Setup HTTPS with NGINX and Certbot

Quartz Technology — Mon, 12 Jun 2023 15:23:33 +0000

Table of content

Why set up HTTPS?
Set up VPS environment
Link domain name to VPS IP
Set up basic Nginx configuration
Use Certbot to enable HTTPS

During the deployment of a new application, it is common to make the application accessible through a domain name.

This is a simple step, really satisfying, but I used to struggle a bit when I started to do it for my first client.

Project architecture are usually the same, you got a proxy like NGINX that will take care of the redirection to your application(s).
As security measure you setup a firewall and open port 80 and 443 to allow traffic on HTTP and HTTPS.

And then it comes to set up HTTPS, and questions like "should I expose my application before enabling HTTPS?", "how do I just do that?", "wait, where do I store those configuration files?".

This article targets beginners who want a simple and fast way to set HTTPS on any application deployed on a VPS.

Why set up HTTPS?

A bit of theory before starting, why is it important to set up HTTPS on your application?

Basically, HTTPS adds a security layer around HTTP protocol thanks to TLS encryption.
When a request is sent with HTTPS, it hides the content of the request, so it cannot be intercepted and used by an attacker.

Here is a great article from CloudFlare for the most curious.

Set up VPS environment

For this guide, I'll use a basic VPS with Ubuntu as operating system and the domain name example.vasek.technology.

To begin, we need to install Nginx and Certbot.

Nginx is a powerful tool for web serving. We will use it to catch requests sent to the domain name and redirect them to the application.
Certbot is a simple CLI to set HTTPS on a server.

You do not need to set up your application to enable HTTPS, you can do that later.

Let's install Nginx.



# Update apt dependencies
sudo apt update

# Install Nginx
sudo apt install nginx -y

This will automatically set up Nginx as a service in your VPS so it will be automatically restart if you shut down your VPS and start it later.

You can verify that Nginx is correctly configured with sudo systemctl status nginx.

You should also see a new folder in etc/nginx containing a lot of files and folders.
Let's not pay attention to them for now.



conf.d          koi-utf     modules-available  proxy_params     sites-enabled  win-utf
fastcgi.conf    koi-win     modules-enabled    scgi_params      snippets
fastcgi_params  mime.types  nginx.conf         sites-available  uwsgi_params

If you go to your IP address on your web browser, you should also see the default Nginx welcome page.

Let's now install Certbot, to do so we will need Python.



# Install python3
sudo apt install python3 python3-venv libaugeas0

# Set up a virtual environment to not conflict with our local one
sudo python3 -m venv /opt/certbot/

# Install pip in this environment
sudo /opt/certbot/bin/pip install --upgrade pip

# Install Certbot with nginx plugin
sudo /opt/certbot/bin/pip install certbot certbot-nginx

# Create a symbolic link to access use certbot from anywhere
sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot

# Verify certbot is installed
certbot --version
# certbot 2.3.0

Link domain name to VPS IP

It is time to link your domain name to the VPS IP, so you can access the page from it.

I personally use Google Domain but any domain name manager works. Let's create a A record that points to your VPS IP.

After few minutes, you should be able to access your website on this domain name.

But as you see, it is still written as not secure. Let's fix that!

Set up basic Nginx configuration

Create a new file nginx.conf anywhere in your VPS and add the most basic configuration that will simply serve the welcome page.
We will set up a symbolic link later to let Nginx use it.



server {
    # Listen on HTTP port (80)
    listen 80;

    # Serve Nginx welcome page
    root /var/www/html;

    # Set domain name to serve.
    server_name example.vasek.technology www.example.vasek.technology;
}

Now we need two last thing.

First, the default index.html page in /var/www/html may not be named properly. By default, Nginx will look for index.html.

In my case, it is always named index.nginx-debian.html, let's rename it
to index.html



# Check for files in /var/www/html
ls /var/www/html
# index.nginx-debian.html

# Rename it to index.html
mv /var/www/html/index.nginx-debian.html /var/www/html/index.html

Secondly, Nginx will process every config files located in /etc/nginx/sites-enabled.
I usually prefer to create a symbolic link to that location, so I can maintain it from my git repository. So others can review it and if it is simpler if I want to change my VPS.



# Create a symbolic link. Make sure to use an absolute path to your nginx config
# file using $PWD variable
ln -s "$PWD/nginx.conf" /etc/nginx/sites-enabled/nginx.conf 

# Show the file to verify the symbolic link has been correctly done.
cat /etc/nginx/sites-enabled/nginx.conf 
server {
    # Listen on HTTP port (80)
    listen 80;
    listen [::]:80;

    # Serve Nginx welcome page
    root /var/www/html;

    # Set domain name to serve.
    server_name example.vasek.technology www.example.vasek.technology;
}

You can also remove the default configure



rm /etc/nginx/sites-enabled/default

Let's verify that our config is correct.



nginx -t
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful

It is normal if you do not see your file in the log, the main config is in /etc/nginx/nginx.conf and includes any files in /etc/nginx/sites-enabled

Now we can reload nginx to apply new configuration.



nginx -s reload

Let's verify if the Nginx is still serving the welcome page on our domain name.

Use Certbot to enable HTTPS

It is time set up HTTPS on our domain name. Let's run Certbot.



# Generate SSL certificate using certbot.
certbot --nginx -d example.vasek.technology --email tom@quartz.technology

Note that the --email is an important option, you should provide a valid address email that will stay in time. This email is used as proof of ownership and is used by site like Whois to record all domain names and their owner.

If you take a look at your nginx.conf, you will see a lot of changes.



server {    
    # Serve Nginx welcome page
    root /var/www/html;

    # Set domain name to serve.
    server_name example.vasek.technology www.example.vasek.technology;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.vasek.technology-0001/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.vasek.technology-0001/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

server {
    # Redirect HTTP to HTTPS
    if ($host = example.vasek.technology) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    listen [::]:80;
    server_name example.vasek.technology www.example.vasek.technology;
    return 404; # managed by Certbot
}

The file has been updated by Certbot to serve HTTPS on your domain name and also redirect HTTP traffic to HTTPS.
It may be a bit messy so clean extra spaces and reorder tabs if necessary.

You can go back on your domain name and see that HTTPS is now enable.

Congratulation! You can now update your configuration to serve your application after deploying it on your VPS.

For example



    # Serve Nginx welcome page
    # Replaced by location
    # root /var/www/html;


    # Redirect request to application listening on
    # port 3000 in the VPS.
    location / {
        proxy_pass http://localhost:3000;
    }

I hope this article was useful to you! I remember my first time struggling to add HTTPS on my first application with 10 different tabs opened about Nginx and its obscure configuration.

Feel free to reach me out or comment if you have any question 🚀

Written by Vasek - Tom C. for Quartz.

DEV Community: Quartz Technology

RETHV - Building Reth for the RISC-V platform

Table Of Contents

Introduction

The RISC-V environnement

Bare Metal

QEMU to the rescue

Cross-Compiling Reth

Cross-Compilation Target

MDBX Bindgen Configuration

Building Reth

Wrapping Up

Custom Docker image for RISC-V toolchain

Using the non-trivial approach

Using a simpler approach

Running Reth

Conclusion

Acknowledgments

Resources

Authors

Setup an Ethereum archive node using Reth on the Orange Pi 5

Context

Prepare the hardware

Prepare the OS

Prepare the archive node

...

...

Copy reth over from the build stage

Conclusion

Use reusable workflows to push images on GitHub Actions

Context

Create a reusable workflow

Use the workflow with matrix

Setup HTTPS with NGINX and Certbot

Table of content

Why set up HTTPS?

Set up VPS environment

Link domain name to VPS IP

Set up basic Nginx configuration

Use Certbot to enable HTTPS