DEV Community: Allan Denot

How to create a Vultr API token

Allan Denot — Thu, 06 Jun 2024 12:22:01 +0000

Step 1: Login to your Vultr Account

Go to https://my.vultr.com/ and login to your account.

Step 2: Enable the Vultr API

Click on your name in the top right corner to access a dropdown menu. Select “API” from this menu:

In the Personal Access Token panel, click the large blue “Enable API” button to activate the API:

Step 3: Manage Your IP Addresses

Once you have enabled the Vultr API, go to the Access Control Area (Account → API) to whitelist your IP address. This allows the ownvpn MacOS app to utilize the API on your behalf.

Vultr automatically whitelists your current IP address when you enable the API. If your IP address changes, remember to update the whitelist.

To check your current IP address, visit: https://api.ipify.org/

If your IP changes frequently, you may opt to whitelist all IP addresses. Note that this is less secure. If you choose this option, take extra precautions to secure your API Personal Access Token.

The ownvpn MacOS app stores your API token in MacOS’s keychain to ensure security.

Step 4: Copy Your Personal Access Token

You can find your Personal Access Token on the API page of your Vultr account at any time. Copy this token and enter it into the ownvpn settings, ensuring it is kept secure.

Step 5. Setup ownvpn App

Open the ownvpn app and select “Settings” from the menu bar.
Under “Provider,” choose “Vultr” and select your desired Country/Region.
Click on “Credentials” and enter the API token you copied from the previous step.
After saving your settings, a green tick will appear next to the “Credentials” button, indicating that your credentials are correctly configured.
You are now ready to create your first VPN instance.

How to create a DigitalOcean access token

Allan Denot — Thu, 06 Jun 2024 12:20:30 +0000

Step 1: Login to your DigitalOcean Account

Go to https://cloud.digitalocean.com/login and login with your credentials.

Step 2: Generate Your DigitalOcean API Token

Log into your DigitalOcean dashboard.
Navigate to “API” in the main menu on the left side.
In the “Tokens/Keys” section, click on “Generate New Token.”
Give your token a name, select "Custom Scopes" to define granular permissions for your token
Select: droplet, regions and sizes
Click "Generate Token"
Be sure to copy your new token immediately; you won’t be able to see it again.

Step 3: Configure the ownvpn App

Launch the ownvpn app and go to “Settings” in the menu bar.
For the “Provider” option, select “DigitalOcean.”
Choose your desired data center region from the “Region” dropdown menu.
Click on “Credentials” and paste the API token you generated earlier.
Once you save your settings, a green tick will appear next to the “Credentials” button to confirm your API token is successfully integrated.

Step 4: Create Your VPN Instance

With the API set up and credentials configured, you are ready to create your first VPN instance using the ownvpn app with DigitalOcean as your cloud provider.

Protecting URLs with AWS ALBs and OIDC in 6 minutes

Allan Denot — Mon, 15 Nov 2021 23:11:19 +0000

00:00:00

Problem: You have a web app with an administration page that should be restricted to internal users.

Here's some of the options that would solve this:

Program authentication into your app, which would be different from your main user login as it's targeted to internal users and not your customers.
Deploy the app privately (like an internal load balancer) and require VPN access
Use some third-party service like Cloudflare Access.

We would like to propose a solution that could be implemented very quickly if you already using AWS Application Load Balancer (ALB).

00:01:00

This example we will authenticate internal users in Google Workspace, but this works with any Identity Provider that supports OIDC/OAuth2.

Go to your Google Cloud Console (linked to your Google Workspace account) as Admin and under "APIs & Services", create a new OAuth2 Client, as shown below:

More details here: https://support.google.com/cloud/answer/6158849?hl=en

In "Authorized JavaScript origins", enter the main URL of your web application (without the /admin path). And in "Authorized redirect URIs" enter the same as before, but adding oauth2/idpresponse to the path.

After creation, copy the Client ID and Client Secret generated to a secure location.

Also make sure your Google project's OAuth Consent is set to Internal, if you want to authenticate only internal users. If your goal is to authenticate anyone with a Google Account, you can leave it External.

00:03:00

Login to your AWS Console, under EC2 select Load Balancers, choose your load balance and edit the Listener Rules, as shown below:

Click the "+" icon to add a new rule.

Click "Insert rule" above the normal URL for your web app (which could be the default action).

In the left side, enter the conditions for the rule. As this example is for path-based, we will enter all paths we want to protect with an OAuth login screen:

Enter all paths ending with a * (remove the trailing slash from the path).

In the right side, enter Add Action > Authenticate, and select OIDC.

And setup Google Workspace OIDC with the following parameters:

Name	Value
Issuer	`https://accounts.google.com`
Authorization endpoint	`https://accounts.google.com/o/oauth2/v2/auth`
Token endpoint	`https://oauth2.googleapis.com/token`
User info endpoint	`https://openidconnect.googleapis.com/v1/userinfo`

And under Advanced Settings, set the Session Timeout to a small value, like 43200 (12 hours), otherwise the authentication will last for 7 days by default.

Just below the OIDC action, you now have to add the Forward action to reach your web app.

Copy the same action as the rule used at the moment to reach your web app. In this example, we were using a Default Action, Forwarding to a Target Group called "Laravel", so we will mimic this action into our OIDC rule, as shown below:

Click on the Save button above to save the new rule.

00:05:00

That's it, now access your web app under the URL protected and you should be redirected to a Google authentication page.

After authenticated, ALB will add a cookie that lasts for 12 hours (or the Session Timeout set before).

If you like this post, you will love our 100+ open source repositories with moslty Terraform modules that help you achieve stuff like this.

Check out our repos at https://github.com/DNXLabs, specially https://github.com/DNXLabs/terraform-aws-ecs-app that comes with this feature built in.

ARM vs Intel - A real-world comparison using EC2

Allan Denot — Wed, 02 Dec 2020 11:38:32 +0000

With the recent move from Apple to ARM-based CPUs, everyone seems to be in awe of the performance of the ARM-based Apple M1s.

As a cloud engineer, I couldn't avoid asking if this performance translates to cloud computing too.

AWS has their line of ARM CPUs called Graviton, available in their second generation as the m6g family in EC2. Those CPUs are on average 20% cheaper for the same amount of vCPUs and RAM, but how do they compare in terms of real-world performance, against traditional Intel CPUs? That's what we are here to find out.

Setup

	Intel	ARM
Instance Count	1	1
Instance Type	m5.large	m6g.large
CPU Tested	Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	Custom built AWS Graviton2 Processor with 64-bit Arm Neoverse cores
CPU Count	2	2
Clock (MHz)	3397.426	N/A
Region/AZ	ap-southeast-2c	ap-southeast-2c
Price (Sydney)	$0.120 per Hour	$0.096 per Hour

cat /proc/cpuinfo didn't show much information for the Graviton CPUs, I guess AWS wants to be secretive about it.

Platform

The goal is to simulate a workload close to a real-world scenario, so we chose to use a Laravel API connecting to a MySQL database, which is a popular stack today.

The infrastructure used:

AWS ECS running in EC2
2 Docker containers (ECS tasks) running the same App in one instance
Containers limited to 1GB RAM (soft and hard limit), but no limit on CPU usage

Application

RealWorld Example API, Laravel
PHP 7.1
Apache/2.4.38 (Debian)

Container

Intel: FROM php:7.1-apache
ARM: FROM arm64v8/php:7.1-apache

Test Tool

ab -n 1000 -c 20 https://${HOST}/api/articles/test-post
^      ^      ^
⎮      |      ⎩ 20 concurrency
⎮      ⎩ 1000 requests
⎩ Apache Benchmark

Results

TL;DR

Graviton2 processors (m6g.large) are on average 25% faster than Intel on an m5.large instance.

Given that m6g.large is 20% cheaper, we get a total of 40% gain in price/performance.

Data (higher is better)

Graviton2 is almost 29% faster when shooting requests to a single container and the database behind is exactly the same.

When adding a second container to answer requests, interestingly Gravitons didn't see any improvement, while Intel did. The difference fell to 8% only

Testing with requests that do not require database access, the number of requests per second were higher for both, and Graviton kept a good margin against Intel of 26%.

As a bonus, we decided to match the same instance type in the database. That means that now the m5.large EC2 instance is connected to a db.m5.large RDS instance and the m6g.large to a db.m6g.large RDS instance.

Results were pretty similar to before, with a 22% advantage to Gravitons, meaning that for this specific test, the database was not a bottleneck.

Final Thoughts

A simple change in your Dockerfile could mean a 40% cost reduction in your compute costs.

As M1 Macs become more popular, dev teams will be multi-platform, requiring environments (both local and cloud) to support different architectures.

Docker also is working on better support for multi-platform images with docker buildx, making it more portable and easier to use the most cost-effective computing platform, independent of architecture.