TLDR; open up https://gitlab.com/alexandersperling/moderncv-boilerplate, fork the repository and follow the instructions.

I don't know about you, but when starting with moderncv on Latex it was not possible for me to really get a hand on how to get this thing up and running or even create a simple pdf of it.

So after some time struggling and spending time in a lot of documentation I've managed to setup some boilerplate repository to (hopefully) save you some time.

So what is moderncv?

The moderncv package provides a document class for typesetting applications (curricula vitae and cover letters) in various styles. moderncv aims to be both straightforward to use and customizable, providing five ready-made styles (classic, casual, banking, oldstyle and fancy) and allowing you to define your own by modifying colors, fonts, icons, etc.

In fact, it provides you a layout for a modern looking cv and a lot of possible options to structure and color it.

Here I'm going to share some best practices (for me).

1. Install Latex for your distriution, there are a lot of different packages, usually the moderncv package is already included.
2. Setup your editor, in my case I use VSCode for editing tex files. With the Latex workshop plugin, you are able to compile your project on the fly and see the result directly in your editor.
3. Fork this repository and adapt the files to your needs. When the changes are commited to Gitlab, a CI job starts and will create your new modernCV pdf file. An example of how this looks, can be found here.

credits:
Foto von Ron Lach : https://www.pexels.com/de-de/foto/arm-hand-reinigung-reinigen-10573240/

Working with AWS CDK , on a daily basis, grants you a lot of possibilities to automate your cloud infrastructure. However, as in every tool, there are sometimes pitfalls which are, at least for me, worth to document.

In CDK, it is possible to import IAM roles by their specific ARN (Amazon Resource Names, starting with arn:partition...).

With that you can easily, lets say during the creation of an eks cluster, set up IAM roles without any permissions and import them later on to grant rights on specific resources, for examples Secrets Manager Secrets.

Lets assume the following setup. We have an app with 2 different stacks. In another app, We've set up an External Secrets Operator helm chart with IAM Roles for ServiceAccounts and want to grant this IAM role now permissions for reading database secrets.

bin
 └───app.ts 
src
 ├───mariadb-stack.ts
 └───postgresql-stack.ts
packagage.json
.stuff-config.json
.
..
...

In our mariadb-stack.ts we define the following.

import { App, Stack, StackProps } from 'aws-cdk-lib';
import { Vpc } from 'aws-cdk-lib/aws-ec2';
import { Role } from 'aws-cdk-lib/aws-iam';
import { Key } from 'aws-cdk-lib/aws-kms';
import {
  Credentials,
  DatabaseInstance,
  DatabaseInstanceEngine,
  MariaDbEngineVersion,
} from 'aws-cdk-lib/aws-rds';
import { Secret } from 'aws-cdk-lib/aws-secretsmanager';

export interface MariaDbProps extends StackProps {}

export class MariaDbStack extends Stack {
  constructor(app: App, id: string, props: MariaDbProps) {
    super(app, id, props);

    const encryptionKey = new Key(this, 'MariaDbKey', {});
    const vpc = Vpc.fromLookup(this, 'MyVpc', {
      vpcId: 'vpc-01234567890abcdef',
    });

    const databaseEngine = DatabaseInstanceEngine.mariaDb({
      version: MariaDbEngineVersion.VER_10_5_9,
    });

    const databaseSecret = new Secret(this, 'DatabaseSecret', {
      description: 'my database secret',
      encryptionKey: encryptionKey,
      secretName: `myDatabaseSecret`,
    });

    new DatabaseInstance(this, 'MariaDbDatabase', {
      engine: databaseEngine,
      vpc,
      credentials: Credentials.fromSecret(databaseSecret),
    });

    const serviceAccountRoleExternalSecrets = Role.fromRoleArn(
      this,
      'ExternalSecretsRole',
      'arn:eu-west-1:iam::123456789:role/MyExternalSecretsOperator',
    );
    databaseSecret.grantRead(serviceAccountRoleExternalSecrets);
  }
}

Our postgresql-stack.ts looks like this

import { App, Stack, StackProps } from 'aws-cdk-lib';
import { Vpc } from 'aws-cdk-lib/aws-ec2';
import { Role } from 'aws-cdk-lib/aws-iam';
import { Key } from 'aws-cdk-lib/aws-kms';
import {
  Credentials,
  DatabaseInstance,
  DatabaseInstanceEngine,
  PostgresEngineVersion,
} from 'aws-cdk-lib/aws-rds';
import { Secret } from 'aws-cdk-lib/aws-secretsmanager';

export interface PostgresqlProps extends StackProps {}

export class PostgresqlStack extends Stack {
  constructor(app: App, id: string, props: PostgresqlProps) {
    super(app, id, props);

    const encryptionKey = new Key(this, 'PostgresqlKey', {});
    const vpc = Vpc.fromLookup(this, 'MyVpc', {
      vpcId: 'vpc-01234567890abcdef',
    });

    const databaseEngine = DatabaseInstanceEngine.postgres({
      version: PostgresEngineVersion.VER_14,
    });

    const databaseSecret = new Secret(this, 'DatabaseSecret', {
      description: 'my database secret',
      encryptionKey: encryptionKey,
      secretName: `myDatabaseSecret`,
    });

    new DatabaseInstance(this, 'PostgresqlDatabase', {
      engine: databaseEngine,
      vpc,
      credentials: Credentials.fromSecret(databaseSecret),
    });

    const serviceAccountRoleExternalSecrets = Role.fromRoleArn(
      this,
      'ExternalSecretsRole',
      'arn:eu-west-1:iam::123456789012:role/MyExternalSecretsOperator',
    );
    databaseSecret.grantRead(serviceAccountRoleExternalSecrets);
  }
}

nearly the same, I know, but it is important that his code comes from 2 different stacks. :)

The interesting part is where we import the IAM role and grant read permissions for the database secret.

    const serviceAccountRoleExternalSecrets = Role.fromRoleArn(
      this,
      'ExternalSecretsRole',
      'arn:eu-west-1:iam::123456789012:role/MyExternalSecretsOperator',
    );
    databaseSecret.grantRead(serviceAccountRoleExternalSecrets);
  }

While this code works it will create one policy and every time we import that role again in another stack and granting permissions to it, this previous policy will be overwritten. When first humbling around this I really wondered why the f***, the service was able to fetch that secret in a previous step but not afterward, until examining the resulting policy and related cdk diff.

Obviously I was not the only one with that problem and so AWS already fixed that in version 2.29. So the way to solve this would look like this. You add a new property to define a default policy name so that different policies per stack will be created.

The resulting code should look like this.

postgresql-stack.ts

    const serviceAccountRoleExternalSecrets = Role.fromRoleArn(
      this,
      'ExternalSecretsRole',
      'arn:eu-west-1:iam::123456789012:role/MyExternalSecretsOperator',
      {
        defaultPolicyName: 'PostgreSqlStackPolicy',
      },
    );
    databaseSecret.grantRead(serviceAccountRoleExternalSecrets);
    

mariadb-stack.ts

    const serviceAccountRoleExternalSecrets = Role.fromRoleArn(
      this,
      'ExternalSecretsRole',
      'arn:eu-west-1:iam::123456789012:role/MyExternalSecretsOperator',
      {
        defaultPolicyName: 'MariaDbStackPolicy',
      },
    );
    databaseSecret.grantRead(serviceAccountRoleExternalSecrets);

This is mainly for documenting the process for getting this blog thing up and running on my server.

When looking for potential blog software and researching cms systems I stumbled over ghost quite early. Starting in 2013 ghost aimed to be a fairly minimal cms for quick and easy blog setups.

Since I was looking for something like this, I decided to give it a try. Another big plus for me is the possibility to run the whole setup in Docker. I like the basic pattern of running services in containers on my server exposed locally and use nginx as reverse proxy to foreward the traffic to those services.

Lets see what we need to do.

First of lets make sure we have docker installed and running.

$ docker --version
Docker version 23.0.1, build a5ee5b1

When using containers the storage is usually ephemeral, that means when the container is stopped for whatever reason the data is gone. We do not want this for our blog so we have to put in some persistence for storing the data.

# creating the volume for our blog itself
docker volume create ghostblog

# creating the volume for the blog database
docker volume create ghostblogdb

We can now start setting up a docker-compose file where the configuration of our containers will happen.

TLDR;

this is the whole file which I used which should work, when the volumes were created beforehand. Following we will take a look into separate parts of this.

version: '3'
services:
  ghost:
    image: ghost:5-alpine
    restart: always
    ports:
      - "127.0.0.1:8888:2368"
    environment:
      database__client: mysql
      database__connection__host: db
      database__connection__user: root
      database__connection__password: myS3cur3Pa$$W0rd)
      database__connection__database: ghost
      url: https://this-should-be-your-url.tld/
    volumes:
      - ghostblog:/var/lib/ghost/content
    depends_on:
      - db
  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: myS3cur3Pa$$W0rd)
    volumes:
      - ghostblogdb:/var/lib/mysql
volumes:
  ghostblog:
  ghostblogdb:

In the first part we define the service ghost itself. The important part can be found in the environment section.

Ghost itself can be configured via environment variables, where nested keys can be combined via two underscores with their top level keys. We define in our setup mainly the database options and the important key which defines our url.

When this is not set correctly ghost will fail to preview your site in the admin and editor area.

Setting the password can be probably also done via Docker Secrets. This has to be created beforehand and needs a separate declaration in the docker-compose.yaml. There is a pretty good blog entry on this by Allan MacGregor on Earthly.

However since this database is running only locally exposed and I do not put this file under version control, I consider this as 'secure enough'.

[...]
environment:
  database__client: mysql
  database__connection__host: db
  database__connection__user: root
  database__connection__password: myS3cur3Pa$$W0rd)
  database__connection__database: ghost
  url: https://this-should-be-your-url.tld/
volumes:
  - ghostblog:/var/lib/ghost/content
depends_on:
  - db

Also we define the volume which was created in the beginning where our content will be stored. I added the for the dependency because when experimenting with the setup I saw very often error messages of ghost itself in the log, that the database connection failed, which came due to the fact that the container was not running yet.

When starting up those containers you should be able to access the ghost default interface on your localhost on port 8888.
In the next part, we will take a look how this works all together with nginx as reverse proxy.

credits
Image by Clker-Free-Vector-Images from Pixabay
https://hub.docker.com/_/ghost
https://ghost.org/docs/config/