DEV Community: Denis AKPAGNONITE

[Boost]

Denis AKPAGNONITE — Sun, 13 Apr 2025 21:00:39 +0000

Denis AKPAGNONITE

Apr 13 '25

How a job interview led me to create Obscura - A password generator with real entropy

#security #privacy #opensource #interview

Comments

5 min read

How a job interview led me to create Obscura - A password generator with real entropy

Denis AKPAGNONITE — Sun, 13 Apr 2025 20:57:54 +0000

Introduction

During a recent interview for a Security Software Engineer position, I was given a challenge: create a secure password generator that takes into account real entropy. The interviewer wanted to see how I would approach the problem, and I was excited to take on the challenge.

At first, I thought it would be a simple task. I had used password generators before (with Math.Random stuffs), and I assumed it would be easy to create one that was secure. But the conversation quickly steered away from superficial implementations and into deeper, often overlooked topic: entropy—and how most so-called generators don't handle it properly.

The challenge

The interviewer insisted on entropy being measurable, adjustable, and predictable based on user choice. He wasn't looking for a simple tool that just throws random characters together; he wanted a password generator that would :

quantify the information entropy of the generated password,
adapt based on character pool constraints (like avoiding duplicates or special characters),
prevent common patterns and sequences (e.g., "123" or "qwerty" or "abc"),
and still generate passwords that are straightforward to use and robust against brute-force attacks.

That got me thinking about how most password generators out there are just glorified random characters generators.

My thought process: understanding entropy

I started by asking him about the definition of entropy in the context of password generation.

He explained that entropy is a measure of uncertainty or randomness in a system. In the case of passwords, it refers to the unpredictability of the password itself.
The more unpredictable a password is, the higher its entropy, and the more secure it is against brute-force attacks. (I said to my-self: come on man, you were supposed to make understand the concept not complicate it 🙁? because I don't know how to measure it, and I don't know how to calculate it).

After a few minutes of discussion, I was given the entropy formula which was quite simple but powerful:

E = log2(P^L)

Where:

E is the entropy in bits
P is the size of the character pool (e.g., 26 for lowercase letters, 10 for digits, etc.)
L is the length of the password

And here is the example of the entropy calculation he gave me:
For a password using 26 chars of lowercase letters and a length of 8:

E = log2(26^8) = 8 * log2(26) ≈ 37.6 bits

Strong passwords should have at least 80 bits of entropy, so I needed to ensure that my generator increases the entropy by using :

A larger character pool (e.g., uppercase and lowercase letters, digits, special characters)
A longer password length
True randomness in character selection (not just pseudo-randomness)

After all these details, I understand two things:

The larger the character pool and the longer the password, the stronger the password.
Entropy is measured in bits, and more bits means more possible combinations.

But if we exclude similar characters, enforce uniqueness, and start with specific characters, the pool shrinks—reducing entropy. So we need to calculate entropy dynamically based on current user choices.

The solution: Build a real password generator

I wrote the first version of the password generator in TypeScript, focused purely on logic. It supports options like:

include/exclude uppercase, lowercase, digits, special characters
exclude similar characters (e.g., "l" and "1", "O" and "0")
avoid duplicates and sequential patterns
generate multiple passwords at once
and most importantly: real time entropy calculation

Design approach

My implementation follows a modular approach centered around the core generatePassword function. I defined a clear PasswordOptions interface to make the code more readable and type-safe.

export interface PasswordOptions {
  length: number
  includeLowercase: boolean
  includeUppercase: boolean
  includeDigits: boolean
  includeSymbols: boolean
  excludeSimilarCharacters: boolean
  noDuplicateCharacters: boolean
  noSequentialCharacters: boolean
  beginWithLetter: boolean
  quantity: number
}

Character Pool generation

The foundation of my code is the character pool selection. I defined constant of character sets and wrote a helper function to build customized pool based on user preferences:

function getCharacterPool(options: PasswordOptions): string {
  let pool = ''
  if (options.includeLowercase) pool += LOWERCASE
  if (options.includeUppercase) pool += UPPERCASE
  if (options.includeDigits) pool += DIGITS
  if (options.includeSymbols) pool += SYMBOLS
  if (options.excludeSimilarCharacters) {
    pool = pool
      .split('')
      .filter((c) => !SIMILAR.includes(c))
      .join('')
  }
  return pool
}

This approach gives users fine-grained control over the character set, which is directly impacting the entropy calculation.

Security considerations

I implemented several security features to ensure strong password generation:

Cryptographically secure randomness: instead of using Math.random(), I used the Web Crypto API crypto.getRandomValues() for true randomness:

     function getRandomChar(pool: string): string {
       const randomIndex = crypto.getRandomValues(new Uint32Array(1))[0] % pool.length
       return pool.charAt(randomIndex)
     }

Sequential character detection: to prevent weak pattens like "abc" or "123", I added a function to check for sequential characters:

    function hasSequentialCharacters(password: string): boolean {
      for (let i = 0; i < password.length - 2; i++) {
        const a = password.charCodeAt(i)
        const b = password.charCodeAt(i + 1)
        const c = password.charCodeAt(i + 2)
        if ((b === a + 1 && c === b + 1) || (b === a - 1 && c === b - 1)) {
          return true
        }
      }
      return false
    }

Input validation: The code prevents impossible combinations, like requiring unique characters in a password longer than the available character pool:

Password generation logic

The core algorithm uses a retry mechanism to ensure all constraints are satisfied:

generate teh first character (optionally a letter)
build the rest of the password character by character
validate against all constraints (uniqueness, sequential patterns, etc.)
if any constraint fails, retry the entire password generation

This approach ensures that every generated password meets all security requirements.

Final output

The generatePassword function ties everything together, enforcing sensible limits(8–64 characters) and generating the requested quantity of passwords:

export function generatePasswords(options: PasswordOptions): string[] {
  const safeLength = Math.max(8, Math.min(options.length, 64))
  const passwords: string[] = []

  for (let i = 0; i < options.quantity; i++) {
    passwords.push(generatePassword({ ...options, length: safeLength }))
  }
  return passwords
}

This implementation balances security, usability, and performance, resulting in a robust password generator suitable for real-world applications.

Why this matter

I learned a lot from this interview challenge, and I realized that most password generators out there are just glorified random character generators. They don't take into account the real entropy. Good password hygiene is crucial—and we've all reused passwords at some point. Tools like Obscura give users confidence and control without compromising on privacy.

Here are few tips for better password security:

always use unique passwords for each account
prefer longer passwords (16+ characters)
avoid predictable pattens or using personal information (like birthdays or names)
use a password manager (Obscura is great for generating strong password to store there)
never, and ever share your passwords with anyone

My journey experience

Unfortunately, my journey with the company didn't go further than the technical interview step. According to their feedback, they're specifically looking for someone with experience in software engineering and formal security certifications like CISSP, CLSSP, COMPTIA Security+, etc.

My background is primarily in software engineering in distributed systems, with a focus on Kubernetes and DevSecOps practices. While I have experience with security aspects like SAST/DAST code analysis, dependency vulnerability scanning, container security, IaC security reviews, and IAM/secrets management, they were looking for someone with a more specialized security background.

Despite not getting the position, I thoroughly enjoyed the interview process and learned a lot from the challenge. I decided to take the opportunity to build something useful out of it, and that's how I ended up creating Obscura.

Try it, Fork it, Share it or Contribute

You can try obscura at obscura.denisakp.me and check the code on GitHub. I would love to hear your feedback, suggestions, or contributions. This project is open-source, and I welcome any improvements or new features you might want to add.

Backup and Restore MongoDB in a Docker Environment

Denis AKPAGNONITE — Sun, 21 Jul 2024 16:26:48 +0000

Introduction

In a previous post, we discussed how to run a MongoDB database in a Docker container. And we learned how to create a 3-node replica set using Docker Compose. If you missed it, you can check it out here.

In this post, we'll cover an essential topic: Backup and Restore MongoDB in a Docker Environment. I'll walk you through the process of creating a full backup of a MongoDB database running in a Docker container and restoring the backup to a new MongoDB container.

The importance of Backups in a Containerized Environment

Containers are designed to be ephemeral, meaning they can be created, destroyed and recreated at any time. While this offers flexibility, it also means that any data stored within a container is at risk of being lost when the container is removed, or lost due to corruption or other issues. Therefore, it's crucial to have a robust backup and restore strategy to protect your data from loss or corruption and ensure data availability and business continuity.

Why backups matter

1- Data Loss Prevention: Backups are essential for preventing data loss due to accidental deletion, corruption, or hardware failure, or other unexpected events. Having a backup ensures that you can recover your data in case of any such event.

2- Business Continuity: Backups are crucial for maintaining business continuity in the event of data loss. Having a reliable backup strategy ensures that you can quickly recover your data and resume operations without significant downtime, especially in containerized environments.

3- Disaster Recovery: Backups are an essential part of any disaster recovery plan. Having a reliable backup strategy ensures that you can quickly recover your data and resume operations in the event of a disaster.

4- Compliance and Legal Requirements: Many industries have strict compliance and legal requirements regarding data.

5- Peace of Mind: Having a reliable backup strategy in place gives you peace of mind knowing that your data is protected and can be recovered in case of any event.

Backup strategies for MongoDB

MongoDB provides several options for backing up your data, including incremental backups, full backups, and differential backups.

1- Incremental Backups: Incremental backups capture only the changes made since the last backup, reducing the amount of data that needs to be backed up and speeding up the backup process, but can be complex to manage and restore.

2- Full Backups: Full backups capture the entire database, including all data and indexes. While full backups are more time-consuming and resource-intensive than incremental backups, they provide a complete snapshot of the database that can be used to restore the database to a specific point in time.

3- Differential Backups: Differential backups capture only the changes made since the last full backup, reducing the amount of data that needs to be backed up compared to a full backup. This can be a good compromise between full and incremental backups, but can be also complex.

In this post, we'll focus on the full backup strategy as it's the simplest and most reliable method for backing up your database.

Performing a Full Backup of MongoDB

Prerequisites

1- Docker and Docker Compose installed on your system.
2- Basic knowledge of Docker concepts such as volumes.
3- Time to complete the tutorial: 6 to 10 minutes.

Step 1: Start a MongoDB container

First, we'll pull the MongoDB image from Docker Hub and start a MongoDB container.

docker volume create mongo-data # Create a volume to persist the MongoDB data
docker run -d --name mongo -v mongo-data:/data/db -p 27017:27017 mongo:7.0-jammy # Start a MongoDB container

Step 2: Run the mongodump command

To create a full backup of your MongoDB database, you'll use the mongodump command, which is an utility provided by MongoDB. This command will create a binary export of your database that can be used to restore the data later.

Run the following from your host machine to create a full backup of your MongoDB database:

docker exec -it mongo mongodump --uri mongodb://localhost:27017/test --gzip --archive=test.archive

In this example my container is named mongo, and my database is named test. Also, notice the --gzip flag, which compresses the backup file to save disk space. My test database contains almost 7000 documents and is about 18MB, and the backup file is about 627KB which represent a significant reduction in size.

Another important thing is the --uri flag, which specifies the connection string to the MongoDB database. In this example, we're connecting to the MongoDB database exposed on localhost on port 27017. If you followed my previous post, you may have a replica set running on localhost:27017,localhost:27018,localhost:27019. In this case, you should replace the connection string with the appropriate one: mongodb://localhost:27017,locahost:27018,localhost:27019/test?replicaSet=rs0.

And if everything goes well, you should see a message indicating that the backup was successful. Something like this:

Step 3: Copy the backup file to your host machine

The mongodump command will create a backup file inside the container. But we need to copy it to our host machine because the container is ephemeral and can be destroyed at any time.

Run the following command to copy the backup file to your host machine:

docker cp mongo:/test.archive /path/to/backup/yourdatabase.archive

Replace /path/to/backup/yourdatabase.archive with the path where you want to store the backup file on your host machine.

If everything goes well, you should see a message indicating that the file was copied successfully. Something like this:

Congratulations! You've successfully created a full backup of your MongoDB database. You can now store this backup file in a safe location and use it to restore your data if needed. When I say safe location, I mean a location different from your local machine because, if your local machine or server fails, you will lose both the database and the backup.

Another option is to use a cloud storage service like AWS S3, Google Cloud Storage, Azure Blob Storage, or MinIo to store your backups. This way, your backups will be safe even if your local machine or server fails. You may also take care of the security of your backups by encrypting them before storing them in the cloud. This ensure the backup integrity and confidentiality.

Performing a MongoDB Restore

Just as important as creating backups is the ability to restore them when needed. The mongorestore command is used to restore a MongoDB backup created with mongodump. In this section, I'll walk you through the process of restoring a MongoDB backup in a Docker environment.

We'll assume that our MongoDB container has been deleted unintentionally 😏, and the attached volume has gone with it. We'll use the backup file we created earlier to restore the data.

Step 1: Start a new MongoDB container

First, create a new volume, and start a new MongoDB container attached to the newly created volume.

docker volume create mongo-data 
docker run -d --name mongo -v mongo-data:/data/db -p 27017:27017 mongo:7.0-jammy

Step 2: Copy the backup file to the new container

Next, copy the backup file from your host machine or get it from the cloud storage to the new MongoDB container. For this example, we will use the backup file we created earlier.

docker cp /path/to/backup/test.archive mongo:/test.archive

Replace /path/to/backup/test.archive with the path to the backup file on your host machine.

Step 3: Run the mongorestore command

Finally, use the mongorestore command to restore the backup file to the new MongoDB container.

docker exec -it mongo mongorestore --uri mongodb://localhost:27017 --gzip --archive=test.archive

This command will restore the data from the backup file to the MongoDB database running in the new container. Notice that we don't need to specify the database name because it's included in the backup file. The --gzip flag is used to tell mongorestore that the backup file is compressed.

If everything goes well, you should see a message indicating that the restore was successful. Something like this:

Best Practices for MongoDB Backups in a Containerized Environment

1- Use Volumes: Store your MongoDB data on a volume to persist it even if the container is destroyed. This ensures that your data is safe and can be easily backed up and restored.

2- Regular Backups: Schedule regular backups of your MongoDB database to ensure that your data is always up-to-date and can be quickly restored in case of any event. Depending on your data, you may need to back up:

Daily: ideal for databases with frequent changes.
weekly: suitable for moderately active databases; with less frequent changes.
monthly: for databases with infrequent changes.

3- Offsite Backups: Store your backups in an offsite location, such as a cloud storage service, to ensure that your data is safe even if your local machine or server fails. Remember to treat your database backups as sensitive data, meaning you should encrypt them before storing them in the cloud, and restrict access to them to authorized staff only.

3- Automate Backups: Set up automated backup jobs to run at regular intervals to ensure that your data is backed up regularly and consistently.

4- Test Restores: Regularly test your backup and restore process to ensure that your backups are valid and can be restored successfully. This will help you identify any issues with your backup strategy and make the necessary adjustments.

After a backup, you should test the restore process in a sandbox environment to ensure that the backup is valid and can be restored successfully. And one more important thing, you should document the restore process, to ensure that any authorized staff can restore the database in case of any event.

Conclusion

In this article, we've covered the importance of backups in a Docker environment and walked you through the process of creating a full backup of a MongoDB database running in a Docker container. I've also shown you how to restore the backup to a new MongoDB container. By following these steps and best practices, you can ensure that your MongoDB data is safe, secure, and always available, even in the event of data loss or corruption. Remember, having a backup is essential, but being able to restore it is even more important. So, make sure to test your backup and restore processes regularly to ensure that your data is protected and can be recovered when needed.

In a future post, we'll cover an interesting topic: Automating MongoDB Backups in a Containerized Environment. I'm pretty sure you'll love it, because it will save you time and effort. Stay tuned!

References

Setting Up a 3-Node MongoDB Replica Set Cluster with Docker Compose

Denis AKPAGNONITE — Fri, 19 Jul 2024 13:51:06 +0000

Introduction

In this blog post, I'll walk you through setting up a 3-node MongoDB replica set cluster using Docker Compose. This guide will assume you're familiar with basic Docker concepts such as Docker Compose, volumes, networks, and health checks, as well as MongoDB concepts like replica sets. So, if you're ready, let's dive in!

What is a MongoDB Replica Set?

A mongoDB replica set is a group of mongoDB instances that host the same data set. In a replica set, one node is the primary node that receives all write operations. All other nodes, known as secondary nodes, apply operations from the primary so that they have the same data set.

MongoDB replica sets offer redundancy and high availability, keeping the database operational even if one or more nodes die. They replicate data across multiple nodes to ensure integrity and availability.

Why Use a MongoDB Replica Set?

1- High Availability: If the primary node fails, a secondary node can be elected as the new primary, ensuring that the database remains available.

2- Data Redundancy: Data is replicated across multiple nodes, ensuring data integrity and availability.

3- Read Scalability: Secondary nodes can serve read operations, distributing the read load across multiple nodes.

4- Automatic Failover: If the primary node fails, a secondary node is automatically elected as the new primary node.

For further reading about MongoDB replication, check out the official MongoDB documentation on replica sets.

Setting Up a 3-Node MongoDB Replica Set Cluster with Docker Compose

Prerequisites

In this guide, we'll use Docker Compose to set up a 3-node MongoDB replica set cluster. Before you start, make sure you have Docker and Docker Compose installed on your machine. If you don't have them installed, you can download them from the official Docker website.

You may also need to have a basic understanding of MongoDB and mongo shell commands. If you're new to MongoDB, you can check out the official MongoDB documentation on MongoDB CRUD Operations.

Step 1: Create a Docker Compose File

Begin by creating a docker-compose.yml file in a new directory. This file will define the services for the MongoDB containers. We'll create:

three services: mongo1, mongo2, and mongo3;
a network called mongo-cluster; and
three volumes: mongo1-data, mongo2-data, and mongo3-data.

Let's dot it:

networks:
  mongo-cluster:
    driver: bridge

volumes:
  mongo1-data:
  mongo2-data:
  mongo3-data:

services:
  mongo1:
    container_name: mongo_rs0
    image: mongo:7.0-jammy
    hostname: mongo1
    command: ["--replSet", "rs0", "--bind_ip", "127.0.0.1,mongo1", "--port", "27017", "--keyFile", "/etc/mongodb/pki/keyfile"]
    volumes:
      - mongo1-data:/data/db
      - $PWD/scripts/mongo/rs_keyfile:/etc/mongodb/pki/keyfile
      - $PWD/scripts/mongo/init.js:/docker-entrypoint-initdb.d/init-mongo.js
    ports:
      - 27017:27017
    networks:
      - mongo-cluster
    healthcheck:
      test: echo "try {rs.status()} catch(err) {rs.initiate({_id:'rs0',members:[{_id:0,host:'mongo1:27017',priority:1},{_id:1,host:'mongo2:27018',priority:0.5},{_id:2,host:'mongo3:27019',priority:0.5}]})}" | mongosh --port 27017 -u '${MONGO_ADMIN_USER:-admin}' -p '${MONGO_ADMIN_PASSWD:-veryStringPassword}' --authenticationDatabase admin --quiet
      interval: 5m
      timeout: 10s
      retries: 3
      start_period: 10s
    environment:
      MONGO_INITDB_ROOT_USERNAME: '${MONGO_ADMIN_USER:-admin}'
      MONGO_INITDB_ROOT_PASSWORD: '${MONGO_ADMIN_PASSWD:-veryStringPassword}'
      MONGO_INITDB_DATABASE: '${DB_NAME:-test}'
      DB_USERNAME: ${DB_USERNAME:-myuser}
      DB_PASSWORD: ${DB_PASSWORD:-mypassword}
  mongo2:
    container_name: mongo_rs1
    image: mongo:7.0-jammy
    hostname: mongo2
    command: ["--replSet", "rs0", "--bind_ip", "127.0.0.1,mongo2", "--port", "27018", "--keyFile", "/etc/mongodb/pki/keyfile"]
    volumes:
      - mongo2-data:/data/db
      - $PWD/scripts/mongo/rs_keyfile:/etc/mongodb/pki/keyfile
    ports:
      - 27018:27017
    networks:
      - mongo-cluster
    environment:
      MONGO_INITDB_ROOT_USERNAME: '${MONGO_ADMIN_USER:-admin}'
      MONGO_INITDB_ROOT_PASSWORD: '${MONGO_ADMIN_PASSWD:-veryStringPassword}'
  mongo3:
    container_name: mongo_rs2
    image: mongo:7.0-jammy
    hostname: mongo3
    command: ["--replSet", "rs0", "--bind_ip", "127.0.0.1,mongo3", "--port", "27019", "--keyFile", "/etc/mongodb/pki/keyfile"]
    volumes:
      - mongo3-data:/data/db
      - $PWD/scripts/mongo/rs_keyfile:/etc/mongodb/pki/keyfile
    ports:
      - 27019:27017
    networks:
      - mongo-cluster
    environment:
      MONGO_INITDB_ROOT_USERNAME: '${MONGO_ADMIN_USER:-admin}'
      MONGO_INITDB_ROOT_PASSWORD: '${MONGO_ADMIN_PASSWD:-veryStringPassword}'

Let's break down the docker-compose.yml file:

We define a network called mongo-cluster that will be used by all the MongoDB containers. This ensures that the containers can communicate with each other through the hostnames mongo1, mongo2, and mongo3.
We define three volumes: mongo1-data, mongo2-data, and mongo3-data to persist the data for each MongoDB container.
We define three services: mongo1, mongo2, and mongo3. Each service runs a MongoDB container with the mongo:7.0-jammy image. We specify the --replSet option to set the replica set name to rs0. We also specify the --bind_ip option to bind the container to the hostnames mongo1, mongo2, and mongo3. We mount the volumes to persist the data and the keyfile for authentication. We expose the ports 27017, 27018, and 27019 for the MongoDB containers. We define a health check for the mongo1 service to check the status of the replica set and initiate it if it's not already initiated. After the healthcheck is successful, the replica set is initiated with the primary node mongo1 and secondary nodes mongo2 and mongo3.
We set the environment variables MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD, MONGO_INITDB_DATABASE, DB_USERNAME, and DB_PASSWORD for each service to configure the MongoDB authentication. We're using interpolation to make sure the default values are used if the environment variables are not set.

Step 2: Create a Keyfile for Authentication

MongoDB uses keyfiles for internal authentication between members of the replica set. In a certain scenario where credentials are not set, we would not need it. But for the sake of this guide, we need to create a keyfile and mount it to the MongoDB containers, since we're using authentication.

To create a keyfile, run the following command:

openssl rand -base64 756 > scripts/mongo/rs_keyfile && chmod 400 scripts/mongo/rs_keyfile

This command generates a random 756-byte key and saves it to the scripts/mongo/rs_keyfile file. We then set the file permissions to 400 to ensure that only the owner mongodb:mongodb can read and write to the file. You can read more about keyfiles in the MongoDB documentation.

Note: the keyfile is used for internal authentication between members of the replica set. It's important to keep the keyfile secure and not expose it to unauthorized users.

Step 3: Create an Initialization Script

As I mentioned earlier, we'll set up an initial database, username and password for the MongoDB replica set. To do so we'll use an initialization script that will be executed when the MongoDB container starts. Now, create a file called init.js in the scripts/mongo directory with the following content:

db = db.getSiblingDB(process.env.MONGO_INITDB_DATABASE)

db.createUser({ 
    user: process.env.DB_USERNAME,
    pwd: process.env.DB_PASSWORD,
    roles: [{ role: 'readWrite', db: process.env.MONGO_INITDB_DATABASE }] 
}, { w: 'majority', wtimeout: 5000 });

Let's break down the init.js file:

We connect to the database specified by the MONGO_INITDB_DATABASE environment variable.
We create a user specified by the DB_USERNAME and DB_PASSWORD environment variables with the readWrite role on the database.
We set the write concern to majority with a timeout of 5000 milliseconds. This ensures that the write operation is acknowledged by the majority of the replica set members.

This script will be executed when the MongoDB container starts, creating the initial database and user for the replica set. Note that the script part is not mandatory, and you could use hardcoded values. However, according to the section III of the 12-factor app, it's better to use environment variables to store secrets or anything that may vary between deployments.

Step 4: Start the MongoDB Replica Set Cluster

Now that we have everything set up, we can start the MongoDB replica set cluster using Docker Compose by running the following command:

docker-compose up -d

Note: The -d flag runs the containers in detached mode, which means they will run in the background.

Step 5: Verify the MongoDB Replica Set

To verify that the MongoDB replica set is running correctly, you can use the mongo shell to connect to the primary node and check the status of the replica set. Run the following command to connect to the primary node:

docker exec -it mongo_rs0 mongosh -u admin -p veryStringPassword --authenticationDatabase admin

Note: Replace veryStringPassword with the password you set for the MONGO_INITDB_ROOT_PASSWORD environment variable. If you didn't set it, use veryStringPassword.

Once connected, run the following command to check the status of the replica set:

rs.status()

You should see the status of the replica set with the primary node mongo1 and the secondary nodes mongo2 and mongo3. The output should like:

members: [
    {
      _id: 0,
      name: 'mongo1:27017',
      health: 1,
      state: 1,
      stateStr: 'PRIMARY',
      uptime: 478,
      electionTime: Timestamp({ t: 1721354075, i: 1 }),
      electionDate: ISODate('2024-07-19T01:54:35.000Z'),
        ...
    },
    {
      _id: 1,
      name: 'mongo2:27018',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      uptime: 471,
      syncSourceHost: 'mongo1:27017',
        ...
    },
    {
      _id: 2,
      name: 'mongo3:27019',
      health: 1,
      state: 2,
      stateStr: 'SECONDARY',
      uptime: 471,
      syncSourceHost: 'mongo1:27017',
        ...
    }
  ],
  ok: 1,
  '$clusterTime': {
    clusterTime: Timestamp({ t: 1721354536, i: 1 }),
    signature: {
      hash: Binary.createFromBase64('8KKPt/SmHkhGZDH299+yq6j5i04=', 0),
      keyId: Long('7393159456961331205')
    }
  },

Note: This is a truncated output, and it may vary depending on the version of MongoDB you're using.

Bonus: Add Mongo-Express for Web-based Administration

Let's add a web-based administration tool for MongoDB, by using mongo-express. To add mongo-express to the Docker Compose file, add the following service definition:

  mongo-express:
    container_name: mongo-express
    image: mongo-express
    ports:
      - 8081:8081
    networks:
      - mongo-cluster
    environment:
      ME_CONFIG_BASICAUTH: false
      ME_CONFIG_MONGODB_ENABLE_ADMIN: false
      ME_CONFIG_MONGODB_ADMINUSERNAME: '${MONGO_ADMIN_USER}'
      ME_CONFIG_MONGODB_ADMINPASSWORD: '${MONGO_ADMIN_PASSWD}'
      ME_CONFIG_MONGODB_URL: mongodb://${DB_USERNAME}:${DB_PASSWORD}@mongo1:27017,mongo2:27018,mongo3:27019/${DB_NAME}?replicaSet=rs0
    depends_on:
      mongo1:
        condition: service_healthy

Note: The mongo-express service depends on the mongo1 service being healthy. This ensures that the replica set is up and running before starting the mongo-express service.

You can access mongo-express at http://localhost:8081 in your browser, and have something like this:

Note: To connect your application to the MongoDB replica set, you can use the connection string mongodb://${DB_USERNAME:-myuser}:${DB_PASSWORD:-veryStringPassword}@mongo1:27017,mongo2:27018,mongo3:27019/${DB_NAME}?replicaSet=rs0.

If everything is set up correctly, you should have something like this in your docker desktop:

Conclusion

In this article, I walked you through setting up a 3-node MongoDB replica set cluster using Docker Compose. We covered the basics of MongoDB replica sets, the prerequisites for setting up a replica set, and the steps to create a Docker Compose file to set up the replica set. I also showed you how to verify the replica set and add a web-based administration tool using mongo-express. I hope this guide helps you get started with MongoDB replica sets and Docker Compose.

In a future post, I'll talk about something more important: how to back up, and restore a MongoDB database in a Docker environment. You may have heard that Docker containers are ephemeral, so it's important to have a backup strategy in place to avoid data loss. Stay tuned for that!

If you have any questions or feedback, feel free to reach out to me.

References

This post has been originally posted on my website

Unlocking the Cloud: My Journey to AWS Cloud Practitioner Certification

Denis AKPAGNONITE — Thu, 09 Nov 2023 13:07:22 +0000

Introduction

After weeks of dedicated study and hard work, I'm thrilled to announce that I've recently achieved a major milestone in
my career. I'm now an AWS Certified Cloud Practitioner! This certification has opened up a world of opportunities in the
cloud computing industry, and I'm excited to share my journey and insights with you.

View my verified achievement

Why Amazon Web Services (AWS)

Do you wonder why AWS? It all began with my intense fascination with cloud computing and the rising need in the labor market for cloud experts. Amazon Web Services has revolutionized the way we think about computing, storage, and
scalability.

Comprehensive services portfolio
With the widest range of cloud services available, AWS is the best option for companies of all sizes and sectors. It offers everything from compute, network, storage, databases, to machine learning and more.
Global Presence
AWS offers low latency and high availability to customers and organizations globally, with data centers and regions located all over the world, ensuring redundancy and expanding applications require this worldwide reach.
Reliability and Security
AWS has a track record of reliability and security. From healthcare to financial services, it drives some of the most important workloads in the world. AWS is a reliable option because of its strong security features and compliance certifications.
A Strong Community and Support
The AWS community is vast and vibrant, offering a wealth of resources, forums, and documentation. You can find support and solutions to your cloud challenges.

In summary, AWS is not just a cloud provider; it's a leader in the industry, offering the most comprehensive, reliable,
and innovative cloud solutions. Choosing AWS is a strategic move that can propel your career and business to new heights
in the world of cloud computing.

The Cloud Practitioner Certification Objectives

The AWS Certified Cloud Practitioner (CLF-C02) exam is intended for individuals who can effectively demonstrate overall knowledge of the AWS Cloud, independent of a specific job role. The exam validates a candidate’s ability to complete the following tasks:

Explain the value of the AWS Cloud.
Understand and explain the AWS shared responsibility model.
Understand security best practices.
Understand AWS Cloud costs, economics, and billing practices.
Describe and position the core AWS services, including compute, network, database, and storage services.
Identify AWS services for common use cases.

The AWS Cloud Practitioner Curriculum

The Exam curriculum covers up to four domains which are:

Cloud Concepts (24% of scored content)
It is necessary to have a fundamental understanding of cloud computing concepts to pass the AWS Cloud Practitioner exam. This domain covers a wide range of subjects, including elasticity, scalability, fault tolerance, and high availability.
Security and compliance (30% of scored content)
Another crucial subject for candidates to AWS Cloud Practitioner exam is security. This domain covers a range of
issues with security, compliance, and accountable management.
Cloud Technology and Services (34% of scored content)
This domain is the most important of the AWS Certified Cloud Practitioner Exam. To be proficient in this part, you need to be familiar with the primary AWS services such as EC2, RDS, EC2, S3, Lambda
Billing, Pricing, and Support (12% of scored content)
You must have a basic understanding of AWS Cloud economics, AWS Billing and Cost Management, AWS support plans, the types of charges, billing processes and how services are billed, the consolidated billing and more.

Study resources

Preparing for the AWS Cloud Practitioner exam involves setting a study schedule, breaking down the topics, and setting
goals. Consistency is key, and I recommend dedicating time each day to study. In addition, make use of AWS white papers
and documentation to deepen your knowledge. One of the key factors that contributed to my success was the availability
of excellent study resources. Here are some of the resources I used:

AWS Training lessons

AWS Cloud Practitioner Essentials: This course is for anyone who seeks an overall understanding of the Amazon Web Services Cloud. You will learn about AWS Cloud concepts, AWS services, security, architecture, pricing, and support to build your AWS Cloud knowledge.
AWS Technical Essentials: This course introduces you to essential Amazon Web Services and common solutions. It covers the fundamental AWS concepts related to compute, database, storage, networking, monitoring, and security.
AWS Cloud Quest: Cloud Practitioner: AWS Cloud Quest is a role-playing game to help you build in-demand AWS Cloud skills.
KodeKloud AWS Cloud Practitioner (CLF-C02): This course was well-structured, and I gained valuable insights. The Billing & Pricing module was particularly enlightening, offering a concise view of AWS cost management.

Get Familiar with AWS: AWS Free tier

AWS Free Tier is a program offered by Amazon Web Services that provides new AWS users with a limited amount of free access to a variety of AWS services for 12 months. It allows you to explore and experiment with AWS cloud services without incurring any charges, making it an excellent starting point for beginners and those looking to get hands-on experience with AWS. AWS Free Tier is a great way to get started with AWS services.

AWS Cloud Practitioner Free Practice test

The greatest way to assess your exam readiness and knowledge is to take practice exams. You should take advantage of the
free AWS Certified Cloud Practitioner practice exam if you want to achieve high scores. The format and substance of
these tests are intended to closely mimic the real exam.

The Exam booking and the Exam day

To initiate the exam process, I had to book a time slot through the Pearson VUE website. The booking process was
straightforward, allowing me to choose a date and time that suited my schedule. Additionally, I needed to purchase an
exam voucher, which costs $100 USD. It's essential to note that the voucher price covers the exam cost.

There were a few crucial decisions to make, including the method of examination and the logistics of booking. I opted to
take the exam at a Pearson VUE test center, mainly because I wanted a controlled and focused environment. While the option of a proctored exam from the comfort of home is available, I saw it as potentially distracting. The center offered a quiet space dedicated to the exam, ensuring minimal disruptions.

The AWS Cloud Practitioner exam consists of 65 multiple-choice questions, and achieving a minimum score of 700 out of 1000 is required to pass. The questions cover a range of topics relevant to foundational AWS Cloud concepts. Upon completing the exam, the results were available immediately. The instant feedback provided a sense of closure to the exam experience, as the screen revealed whether I had passed or not.

Three days after successfully passing the exam, I received my digital badge on Creedly, a tangible symbol of my accomplishment. Accompanying the badge was a congratulatory email containing valuable instructions and information on
the next steps in my AWS certification journey. This swift response from AWS added a personal touch to the certification
process, emphasizing their commitment to recognizing and celebrating the achievements of candidates.

Outro

If you're considering pursuing an AWS certification, especially the AWS Cloud Practitioner, remember that you're not alone in this journey. Feel free to reach out with any questions or for guidance. The world of AWS and cloud computing is filled with endless possibilities, and I can't wait to see where it takes you.

Conclusion

Finally, for anyone interested in cloud technology, the AWS Cloud Practitioner certification is a great place to start.
It gives you the fundamental information you need and provides access to a variety of career options in the cloud computing area. As I rejoice in my accomplishment, I'm already actively preparing for the AWS Solutions Architect Associate certification, a step I plan to take within the next six months. This ongoing commitment to learning and growth reflects my dedication to staying at the forefront of cloud technology and furthering my expertise in the AWS ecosystem.

I hope that my experience has motivated you to get your AWS certification. I wish you well and the realization of your
cloud computing goals.

This post has been originally posted on my personal web site Dev Life