Divider

![](/images/Screenshot%202025-03-30%20210853.png)

In this post we are going to explain how to expose our service through a Cloudflare VPN **for free**, no matter where we are deploying.

## Why this is important?

When exposing our service directly to the internet, we lack the ability to effectively manage a DDoS attack. Instead, we can use Cloudflare as a reverse proxy and delegate that responsibility to them. Another key reason is that we should avoid exposing our IP address at all costs. This enhances our privacy and helps prevent issues like censorship. For instance, if an ISP or agency wanted to censor us, they would need to block a Cloudflare nameserver, which would disrupt countless other websites as well.

## Top 5 IT Companies Using Cloudflare Protection

*   IBM

*   GitHub

*   GitLab

*   Atlassian

*   Zendesk

## How to use Cloudflare zero trust?

### Create a "Tunnel" under zero trust > networks > tunnels.

### ![](/images/image_2025-04-06_211944711.png)

Run a cloudflare vpn on your server.

I am using a docker container but you can use [cloudflared cli](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/do-more-with-tunnels/local-management/create-local-tunnel/) as well.

```
version: '3'
services:
  httpd_alpine_demo:
    image: httpd:alpine
  vpn:
    image: cloudflare/cloudflared
    restart: unless-stopped
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=_CLOUDFLARE_TOKEN_
```

[View docker-compose.yml file on GitHub](https://github.com/byli-dev/cloudflare_tunnel_demo)

As you may notice, we don’t need to expose our Docker service port to the host because both services are on the same network.

We should use the service name we are exposing as dns.

![](/images/image_2025-04-08_000810504.png)

And that's it !

You can [Visit Demo and follow us on GitHub !](https://zero-trust.byli.dev)![](/images/image_2025-04-08_001014400.png)


Hide Your Server's IP While Exposing Your Service

![guide architecture](/images/log_management_explained.png)

The guide will be concise, so I won't delve too deep. There are three key components to log management that you need to know about.

1. **Data Ingestion**: The process of collecting and capturing logs from various applications into a single location is essential for efficient log management. This is where Promtail comes into play—a powerful and flexible tool that enables effective log scraping. Promtail searches for and sends logs to a centralized system for processing and storage.

2. **Log Storage**: Once the logs are collected, you need a reliable and efficient place to store them. In this case, we use Loki, a high-performance log storage solution. Loki is specifically designed to handle large volumes of logs and offers exceptional scalability. Using a label-based approach, Loki organizes and searches logs, making management and subsequent analysis easier.

3. **Visualization Tool**: With the logs stored in Loki, you need a way to visualize and analyze them effectively. This is where Grafana comes in—a leading data visualization and monitoring platform. Grafana seamlessly integrates with Loki, allowing you to create customized dashboards, interactive graphs, and alerts based on log data. With Grafana, you can have a clear, real-time view of what's happening in your applications.

In this case, we have chosen Promtail, Loki, and Grafana as our tools for log management. However, it's important to note that there are many other options available in the market. The fundamental concept of ingesting, storing, and visualizing logs applies regardless of the specific tools you choose. You can tailor this guide to your own needs and select the tools that best fit your requirements.

![grafana architecture](/images/grafana_architecture.png)

# Steps

### Create docker compose file

```yaml

	version: "3.8"

	services:

	grafana:

	image: grafana/grafana:latest

	hostname: 'grafana'

	volumes:

	- /home/byli-server/nfs/volumes/grafana:/var/lib/grafana

	ports:

	- "3003:3000"

	networks:

	- logs

	promtail:

	image: grafana/promtail:latest

	command:

	- '-config.file=/etc/promtail/promtail-config.yaml'

	volumes:

	- /home/byli-server/nfs/volumes/promtail/config/promtail.yaml:/etc/promtail/promtail-config.yaml

	- /var/log/kern.log:/var/log/kern.log:ro

	restart: always

	networks:

	- logs

	loki:

	image: grafana/loki:latest

	volumes:

	- /home/byli-server/nfs/volumes/loki/config/loki.yaml:/data

	command: -config.file=/etc/loki/local-config.yaml

	restart: always

	networks:

	- logs

	networks:

	logs:

```

### Configure promtail

Create a configuration file `/home/byli-server/nfs/volumes/promtail/config/promtail.yaml` based on the Docker Compose. In this file, we need to include labels for the hostname or node (byli-server). Specifically, we will use the "kernlog" label to indicate that our client should send new events to Loki for kernel logs."

```yaml
server:

http_listen_port: 9080

grpc_listen_port: 0

positions:

filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

pipeline_stages:
  - match:

selector: '{job="kernel-errors"}'

stages:
  - regex:

expression: "error|fail|panic"

scrape_configs:
  - job_name: kernel-errors

static_configs:
  - targets:

  - localhost

labels:

job: kernlog

host: byli-server

__path__: /var/log/kern.log
```

### Configure Loki

Create a configuration file `/home/byli-server/nfs/volumes/loki/config/loki.yaml` based on the Docker Compose.

- **ingester**: Configures the ingester of Loki.

- **lifecycler** : Configures the lifecycle of the ingester.

- **ring**: Configures the ring used by the ingester.

- **kvstore**: Configures the storage for the ring.

- **store**: boltdb: Uses BoltDB as the storage for the ring.

- **chunk_idle_period**: Sets the idle period of chunks to 5 minutes.

- **chunk_retain_period**: Sets the retain period of chunks to 30 seconds.

- **table_manager**: Configures the settings of the table manager.

- **retention_deletes_enabled**: true: Enables deletion of logs based on retention.

- **retention_period**: 720h: Sets the retention period of logs to 720 hours.

These configurations specify that Loki uses BoltDB as the storage for the ingester's ring. The chunk idle period is set to 5 minutes, and the chunk retain period is set to 30 seconds. The table manager is enabled to delete logs based on retention, and the retention period for logs is set to 720 hours.

```yaml

auth_enabled: false

server:

http_listen_port: 3100

grpc_listen_port: 9095

ingester:

lifecycler:

address: 127.0.0.1

ring:

kvstore:

store: inmemory

replication_factor: 1

chunk_idle_period: 5m

chunk_retain_period: 30s

schema_config:

configs:

- from: 2023-01-01

store: boltdb

object_store: filesystem

schema: v11

index:

prefix: index_

period: 24h

storage_config:

boltdb:

directory: /data/loki/index

filesystem:

directory: /data/loki/chunks

limits_config:

enforce_metric_name: false

reject_old_samples: true

reject_old_samples_max_age: 168h

chunk_store_config:

max_look_back_period: 0s

table_manager:

retention_deletes_enabled: true

retention_period: 720s

```

We appreciate your feedback and are glad to hear that the instructions provided were helpful in achieving the desired outcome. If you have any further questions or if there's anything else we can assist you with, please let us know. We're here to help.

Unifying Log Management: A Guide to Ingesting, Storing, and Visualizing Logs from Various Applications

## Requirements

I needed a cronjob-based webhook with retries. In other words, if I had a service called 'X' with 10 replicas, I wanted a CronJob that would execute only once on any of those replicas. Additionally, I wanted to ensure that the cron job had resilient retry strategies in case of failures.

## 💡 Solution Implemented

We leveraged a CronJob in Kubernetes to address this requirement. We defined the desired schedule for the cron job, but how did we ensure it only ran on a single replica? The solution wasn't to rely on code-based scheduling because with our "10 replicas," the schedule would execute on each of them, which didn't serve our purpose.

Instead, we used a CURL image of type 'Webhook.' By doing this, we knew that the request executed by the CronJob would be load-balanced by Kubernetes. This approach not only enabled us to target a single replica but also provided built-in retry strategies if the CURL request (e.g., CURL -X POST) didn't return a 200 OK status code.

🚀 By combining Kubernete's powerful scheduling capabilities like  [cronJob](https://crontab.guru/?ref=0.0.0.0#10_*_*_*)  and the use of a CURL image, we achieved our goal of executing a distributed cron job with retry resilience. This solution offered the scalability and reliability we needed while leveraging the strengths of the Kubernetes ecosystem.

```bash
apiVersion: batch/v1
kind: CronJob
metadata:
  name: firsts-cronjob
spec:
  schedule: "00 00 1 * *" 
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: firsts-cronjob-container
              image: curlimages/curl
              resources:
                limits:
                  cpu: "1"
                  memory: "300Mi"
                requests:
                  cpu: "1"
                  memory: "300Mi"
              args:
                - /bin/sh
                - -c
                - |
                  date
                  echo "Starting CronJob"
                  resp=$(curl -X POST -I -s -o /dev/null -w "%{http_code}" --http2 http://service-x:80/webhook | cut -d$' ' -f2)
                  if [ "$resp" -ne 200 ]; then
                    echo "Error: failed with http: $resp" && exit 1
                  else
                    echo "Success: http: $resp" && exit 0
                  fi
          restartPolicy: OnFailure
  successfulJobsHistoryLimit: 12
  failedJobsHistoryLimit: 12
```

### Retries example

![](/images/k8s-cronjob.png)

HTTP != 200's

## **Common Problems**

Recently, I was working at this company where they had this hilarious issue with cron jobs. They were like, "Don't even think about using cron jobs with Kubernetes! We tried it once, and it was a disaster!" 😭🚫

So, guess what the genius "pseudo-IT" team did to handle distributed cron jobs? They created their own janky solution! They built a project from scratch to manage cron jobs, complete with database locks and tightly coupled code using the @Schedule annotation in Spring Boot. But here's the catch: no architecture, no documentation, and no best practices whatsoever!

Can you believe it? Instead of trusting a battle-tested and widely-used tool like Kubernetes, they went on an adventure to reinvent the wheel. And guess how they determined if their cron job was successful? Brace yourself... they didn't care about the actual HTTP response code! They just returned an exit 0, considering it a triumph every time. 🙃

```
              args:
                - /bin/sh
                - -c
                - |
                  date
                  echo "Starting card CronJob"
                  curl -X POST --http2 http://service-x:80/webhook 
                  exit 0
              restartPolicy: OnFailure
```

this is the reason why the company decided to spend 3 to 4 months developing a new project (how much theft)

## Conclusion

> Never underestimate the tried-and-true tools that have been battle-tested by the IT community. Don't be tempted to take shortcuts and reinvent the wheel when there's a perfectly good solution available. Embrace the tools that have proven their worth and save yourself from unnecessary headaches! 💡

Resilient CronJob-based Webhook in K8S for Distributed services

### 1. Check Existing SSH Keys

Before proceeding, check if you already have SSH keys generated on your system. Open a terminal and run the following command:

`ls ~/.ssh` 

If you see files named `id_rsa` and `id_rsa.pub`, it means you already have an SSH key pair. If not, you can generate a new key pair using the following command:

`ssh-keygen -t rsa -C "your_email@example.com"` 

Replace `"your_email@example.com"` with your email address associated with the Git account. This will create a new SSH key pair in the `~/.ssh` directory.

### 2. Create a "config" File

Next, we'll create a `config` file in the `~/.ssh` directory to specify which SSH key to use for different Git accounts. Open the terminal and enter the following command:

`nano ~/.ssh/config` 

This will open the Nano text editor to create or edit the `config` file.

### 3. Add SSH Key Configuration

In the `config` file, we will define different configurations for each Git account based on specific conditions. For example:
```
Match host github.com exec "pwd | grep personal"
IdentityFile ~/.ssh/personal

Match host github.com exec "pwd | grep work_1"
IdentityFile ~/.ssh/work_1

Match host gitlab.com exec "pwd | grep work_2"
IdentityFile ~/.ssh/work_2
``` 

Explanation of the above configuration:

-   `Match`: This is used to match a specific condition before applying the configuration.
-   `host`: Specifies the hostname for which the configuration should be applied (e.g., github.com, gitlab.com).
-   `exec`: Executes a shell command to check if the condition is met. In this case, we use `pwd | grep` to match the current working directory.
-   `IdentityFile`: Specifies the path to the corresponding SSH private key for the matched condition.

The example assumes you have three SSH key pairs named `personal`, `work_1`, and `work_2`, and they correspond to different Git accounts on GitHub and GitLab.

### 4. Save and Exit

After adding the necessary configurations, save the file and exit the text editor. In Nano, you can do this by pressing `Ctrl + X`, then confirming the save by typing `Y` and pressing `Enter`.

### 5. Test the Configurations

To ensure that the configurations are working as expected, navigate to the directories associated with your different Git accounts and check if the corresponding SSH keys are being used. For example:

```
cd ~/projects/personal-repo
git pull

cd ~/projects/work-1-repo
git pull

cd ~/projects/work-2-repo
git pull
```

If everything is set up correctly, Git should automatically use the appropriate SSH key based on the directory you are in.

That's it! Now you can manage multiple Git accounts seamlessly with the right SSH keys, making your development workflow more efficient and hassle-free.

Devops & infrastructure

Hide Your Server's IP While Exposing Your Service

Unifying Log Management: A Guide to Ingesting, Storing, and Visualizing Logs from Various Applications

Resilient CronJob-based Webhook in K8S for Distributed services

How to use multiple accounts in git?