In DigitalOcean, each of the projects is organized with two separate VPCs:

• Public VPC: Hosts resources accessible from the internet (e.g., Docker Swarm nodes, load balancers).

• Private VPC: Hosts internal resources (e.g., databases, internal load balancers).

To enable secure communication between the public and private VPCs within the same project, we use VPC Peering. This setup ensures private, low-latency communication without exposing private resources to the internet.

Steps to Add a New Peering Connection

Step 1: Create the VPC Peering Connection

1. Go to the Networking section in the DigitalOcean Control Panel.

2. Click on the VPC tab.

3. Click Create Peering Connection.

4. In the configuration form:

   • VPC Network: Choose source VPC for peering.

   • Peer to VPC Network: Select the destination VPC from the dropdown.

   • Add a descriptive name for the peering connection (e.g., public-to-private-peering-prod).

5. Confirm and save the configuration.

Step 2: Configure Firewall Rules

1. Go to the Networking section in the DigitalOcean Control Panel.

2. Click on the Firewalls tab.

3. Іelect the required firewall.

4. Update the rules to allow traffic from the source or destination VPC.

Step 3: Update Route Tables on Droplets

1. Login to the target Droplet

2. Use the following commands to restart network stack

   sudo systemctl restart systemd-networkd

3. On Droplets created before 2 October 2024, or Droplets using custom base images, VPC peering routes must be added manually

   VPC_GATEWAY_IP=$(curl -s 169.254.169.254/metadata/v1/interfaces/private/0/ipv4/gateway)
   
   ip route replace 10.0.0.0/8 via ${VPC_GATEWAY_IP} dev eth1 mtu 1500 metric 101
   ip route replace 172.16.0.0/12 via ${VPC_GATEWAY_IP} dev eth1 mtu 1500 metric 101
   ip route replace 192.168.0.0/16 via ${VPC_GATEWAY_IP} dev eth1 mtu 1500 metric 101

Refer to the official DigitalOcean documentation for more info – https://docs.digitalocean.com/products/networking/vpc/how-to/update-peering-routes/

Step 6: Document the Peering Connection

1. Record the following details for future reference:

   • Source VPC and Target VPC IDs.

   • The CIDR blocks of both VPCs.

   • Name of the peering connection.

   • Any updated firewall rules or routes.

Prod Environment (CRM)

Stage Environment (CRM)

This document provides an overview of the key DNS entities used in managing domain names, including details about registrars, domain names, and name servers (NS).

This document outlines the disaster recovery setup for the PostgreSQL cluster deployed as a managed database on DigitalOcean. The configuration ensures high availability, data integrity, and quick recovery in the event of an incident.

Common Failure Scenarios and Recovery Steps

1: Primary Node Failure

Impact

• The primary node becomes unavailable, affecting write operations.

Recovery Steps

1. Promote an existing read-only node to become the primary node of the database cluster.

   doctl databases replica promote <database-cluster-id> <replica-name> [flags]

2. Update DNS record in prod.rockengroup.comdomain with a new connection strings if the primary node changes due to failover.

3. Provision a new read-only node to maintain redundancy.

2: Cluster Failure

Impact

• Both the primary and read-only nodes are unavailable, resulting in a complete loss of database access.

Recovery Steps

1. Initiate the restoration process through DigitalOcean interface. Use the PostgreSQL: Digital Ocean restore DB document for restoring

2. Ensure the restored databases are consistent and free of corruption.

3. Update connection string in prod.rockengroup.com domain to point to the newly restored cluster.

4. Set up a new read-only node for redundancy.

3. Data Failure

Impact

• Data corruption or accidental deletion affects database integrity.

Recovery Steps

1. Use Snapshooter (PostgreSQL: Snapshooter restore DB) to restore the database to a point-in-time before the data failure occurred:

   • go to backup-snapshooter-prod Space and find necessary DB archive

     

   • download MANUAL_RESTORE.txt file and follow its recommendations to restore the DB .

2. Check the restored data for consistency and completeness.

• PostgreSQL: Digital Ocean restore DB
• PostgreSQL: Snapshooter restore DB
• PostgreSQL: Disaster Recovery Plan

Content

General info

This feature aims to enhance the applicant experience by presenting only relevant hard skills based on the job category of their application. By mapping hard skills to their corresponding categories, applicants will see skills directly related to their job application first, followed by less relevant categories. This improves clarity and reduces the overwhelming number of skills displayed, increasing accuracy and engagement during the application process.

Problem:

When applying during the interview process, Applicants see all our Skills and often do not know which to select because there are too many.

Solution:

Display suggestions with relevant Hard skills to the Job they applied. Therefore, the Skills will be mapped with the categories we have. After, the first that have been mapped to the category will be displayed first.

For example, regarding a person that applied for an IT-Job, it should look like the following:

Hardskills (relevante Kategorien gemäss deiner Bewerbung)

• IT

• Projektmanagement

Hardskills (weniger relevante Kategorien)

• ………. (all other Hardskill Categories)

………

(Jobcategory/Skill Category)

• Banking & Assurance – Branche / Produkte / Lösungen, Sales

• Einkauf und Supply Chain Management – Einkauf / Supply Chain, Sales

• Finanzen – Finanzen, Sales, Projektmanagement

• Healthcare – (ALL)

• Human Resources – HR

• IT – IT, Projektmanagement

• Marketing & Design – Marketing

• Recht / Beratung – Legal

• Sales & Trading – Sales, Finanzen

• Technik / Engineering / Produktion – Technik / Engineering / Produktion, KVP Kontinuierlicher Verbesserungsprozess

The system will suggest relevant hard skills to candidates during the interview process. These suggestions will appear as clickable tags (chips) displayed above the search bar. These tags will be generated based on the job category of the application and the candidate’s experience. Candidates can select these suggested skills by clicking on the tags, and the selected skills will be added to their profile with a default confidence level, which they can adjust. This enhancement simplifies the skill selection process, improves accuracy, and ensures better matching with job requirements.

User story

As a Talent Profile (candidate),
I want to see relevant skill suggestions as clickable tags during the interview process,
So that I can quickly and accurately add skills matched to the job category of my application.

Visual design:

https://www.figma.com/design/I5CXH7H3ICD0vfA1kPbcVf/Rocken-Design?node-id=43746-43924&t=Nxh6fnAACkdYzdPl-1

https://www.figma.com/design/I5CXH7H3ICD0vfA1kPbcVf/Rocken-Design?node-id=43746-44254&t=Nxh6fnAACkdYzdPl-1

Redis is deployed as a service in DigitalOcean with primary and standby nodes. It functions as a cache for a PostgreSQL database and does not include critical data.

Steps to Create a Redis Service in DigitalOcean:

1. Navigate to Managed Databases:

   • Go to the "Databases" section in the control panel.

   • Click on "Create Database."

2. Select Redis:

   • Choose Redis as the database engine.

   • Select the version: Redis 7 (Caching).

3. Configure Cluster Settings:

   • Choose the region (FRA1), node size, set Eviction policy as allkeys-lru`

   • Enable high availability by selecting primary and standby nodes.

   • Add trusted sources (IP addresses) that can access the Redis cluster.

4. Assign a name to Redis cluster (according to naming convention) and click "Create Database."

Redis Cluster Details:

The communication between the application and the Redis cluster is exclusively routed through the internal VPC, with access to the public endpoint restricted.

Since Redis functions as a cache for a PostgreSQL database and does not include critical data, the disaster recovery plan prioritizes service availability and quick recovery.

Architecture

Primary-Standby Nodes: Redis operates with a primary node and a standby replica for high availability. Standby nodes  automatically replace the primary node in the case of a failure, ensuring your data stays available.

Common Failure Scenarios and Recovery Steps

1. Primary Node Failure:

Impact:

• The cluster remains operational.

• Standby node is automatically promoted to replace it

Recovery Steps:

• Follow DigitalOcean instruction to fix the issue

2. Region Failure:

Impact:

• The cluster becomes unavailable.

Recovery Steps:

• Deploy Redis cluster in another DigitalOcean region

• Set new username/password in the application variables

1. Navigate to the Deployment Directory

   • Navigate to the directory where the Docker Compose file will be stored:
     /root/elasticsearch.

   • If the directory does not exist, create it:

     mkdir -p /root/elasticsearch
     mkdir -p /root/elasticsearch/certs

2. Prepare the docker-compose.yml File

   • Place the docker-compose.yml file in the directory.

   • Modify the file as needed to suit deployment requirements.

3. Copy Self-Signed Certificates

   • Copy your self-signed certificates to a folder named certs inside the deployment directory

4. Run the Docker Compose File (Initial Attempt)
   Run the following command to start the deployment:

   docker-compose up -d

The first run may fail because the certs folder must be placed in the elastic-config Docker volume.

5. Prepare the .env File

   • Copy the .env file to the /root/elasticsearch directory.

   • Modify the file as needed to suit deployment requirements.

6. Deploy the Elasticsearch Cluster

   • Start the containers with the following command:

     docker-compose up -d

Useful Docker Commands:

• Get container logs (in real-time, last 200 lines):

  docker logs -f -n200 elasticsearch-docker-node-1

• Get detailed information about the container:

  docker inspect elasticsearch-docker-node-1

• View resource usage statistics:

  docker stats elasticsearch-docker-node-1

• Stopping and Removing Containers

  docker-compose down

Content

General info

This story focuses on implementing a banner on the RockenTalent login page for candidates, informing them about an upcoming platform update. The banner must be responsive to work seamlessly on both desktop and mobile views, and include a close (X) button for user convenience. It aims to communicate scheduled downtime, the improvements coming to the platform, and to assure users that the wait will be worthwhile.

User story

As a Rocken Talent user,
I want to see a banner on the login page that informs me about the upcoming platform update,
So that I am aware of the planned downtime and the new features being introduced.

Visual design:

https://www.figma.com/design/I5CXH7H3ICD0vfA1kPbcVf/Rocken-Design?node-id=59892-476&t=ArrGyYnB7TaeKLGa-4