DEV Community: Juan Carlos García Martínez

Oracle Cloud free tier: Create your free personal VPN using Tailscale

Juan Carlos García Martínez — Tue, 01 Mar 2022 23:05:06 +0000

Introduction

I've found myself in a situation when I'd like to be in other region to avoid some content restriction. I know there are free options with easy installs, but I'm concerned about others spoofing in my traffic. That sounds familiar to you?

I've got you covered! With a little bit of work, you can configure your own VPN for free, with a server configured in the US that will route your traffic, just like if you were in the United States. This is a feature from Tailscale, called exit-nodes which happens to have a free plan. Running a server in a cloud provider may cost you some bucks, but Oracle Cloud has a generous always-free tier that suits us perfectly for this task. So, we'll be using free resources to accomplish our mission.

First and foremost, we need to create our accounts. The account creation for Oracle Cloud is described under
https://www.oracle.com/cloud/free/ Sign up section. We won't dig into that account creation here, but the only thing you'll be aware is of your home region, be careful and set that option to some region in the United States.

Once you have access to Oracle Cloud, we'll jump into the creation of our Tailscale account.

Let's go to https://login.tailscale.com/start to create our account. You'll need to use a third-party identity provider, so choose the one you feel more comfortable with.

You'll be asked to grant permissions to Tailscale for accessing your account's data, click Allow.

Next there is an installation guide for a lot of operative systems, but we'll stop right there for now and jump into our VM creation.

Go to your Oracle Cloud account,Find to Compute > Instances section and select Create Instance.

So, we need name for the VM. I'll use tailscale-exit-node. Then, there is a placement section, to specify where this VM should be created. We can collapse this section and leave it just as it is.

In Image option, select Ubuntu 20.04 and for Shape change it to the following options:

Instance type: Virtual Machine
Shape series: Ampere
Shape name: VM.Standard.A1.Flex
Number of OCPUs: 1
Memory: 6 GB at most

Under Network section, you’ll see a Virtual Cloud Network setup. We’ll skip that section and use the default values.

Then, we will go to Add SSH keys. These keys allow us to log in remotely to our VM, select Generate a new key pair for me and download the private key using the "Save Private Key option" before clicking on create instance.

Lastly, check on "Use in-transit encryption" under boot volume options.

Now, we can click on "Create" button.

You will see a page with the details of the instance, which shows a PROVISIONING state on the upper left, which means our VM is under creation. Look for the Instance Access section and copy the Public IP Address value, which we will use to access our server. Provisioning the VM may take around 5 minutes, but once it is ready, it'll appear in RUNNING state.

Remember that private key you just downloaded? keep it safe since its your access to the server!. For accessing the server we will use in the terminal:

ssh -i [my-private-key] ubuntu@[PUBLIC_IP]

But replacing [my-private-key] with your private key location, and [PUBLIC_IP] for the IP you copied before.

Once we're there, we'll begin with the tailscale installation.

If you go to https://tailscale.com/download/linux, you'll see there is a one-line command to begin the installation, so we'll use that command in our terminal connected to the VM:

curl -fsSL https://tailscale.com/install.sh | sh

Your VM will work for some seconds, and when installation finishes a message will appear:



Installation complete! Log in to start using Tailscale by running:

sudo tailscale up

Before running the command to start tailscale, let's enable the IP forwarding feature in our server. For that, copy the following commands in the terminal:



echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

//Adverstising node from shell and tailscale admin

Ok then!, then, let's run the command with an additional flag, that will mark this machine as a traffic forwarder:

sudo tailscale up --advertise-exit-node

You'll get another message in the console similar to this:



To authenticate, visit:

    https://login.tailscale.com/a/[SOME_ID]

Copy the link in the browser, log in using the Tailscale account you created before. In your browser, you'll get a message indicating that is good to close the tab, so please do it. In your terminal, you'll see a Success message.

//Log in using mobile or another client

Next, we will configure our own machine to connect to the remote server and use it as a bridge for our internet traffic. Go to https://login.tailscale.com/admin/welcome and follow the on-screen instructions for your local OS. (Windows, macOS, Linux, or iOS and Android devices). Once this is done, you will see two machines in your admin page.

Under the same page, go to the three-dot menu in the row of our tailscale-exit-node and click on Edit route settings.... Then, turn on the switch for enabling the exit node option.

We're almost done with the configuration!.
Lastly, we should go to our other device, and use that exit node we configured.

In Android, you can click the three-dot menu, next Use exit node... and select the option of tailscale-exit-node.

And that's it!. Now, you're faking the internet believing that your IP is the one from the server we configured, which happens to be in the US!. In reality, all the internet traffic is now routed through that server you own, in a secure way so nobody can spoof.

If you want to confirm this, you can use whatismyip.com site to check that the IP address in your local device is the same that the one in your server.

Remember that using a Tailscale VPN exit node can also secure your traffic when using non-trustable public networks, such as a coffee shop WiFi, the hotspot in the airport or any other public place. You can add up to 20 devices to this VPN for free; such as mobiles, laptops and tablets that can use the exit node we configured. If you need more than that, you can upgrade your Taiscale plan.

I hope you find useful this guide! I'll try to share more ways you can use Oracle Cloud for free, for those who are new in the cloud world and want to experiment without risk to have any surprising bills.

Oracle Cloud free tier: Set up a free web Visual Studio Code

Juan Carlos García Martínez — Sat, 20 Nov 2021 01:16:20 +0000

Using the free tier of Oracle Cloud, you can create an instance with up to 4 cores and 24 GB of RAM! That's enough for most of my development tasks, and this comes included in Free Tier!.
If you can't switch to ARM architecture, there is option for 2 VMs with 1-core AMD x64 and 1 GB of RAM.

This kind of setup might be useful if you're someone that wants to have a development environment on-the-go, and code in your iPad or a laptop with limited resources, or if you're someone who likes to experiment just like me.

In this guide, we will configure a VM with an Ampere ARM processor to run visual studio code on the web.

First of all, you need to create an account in Oracle Cloud, and remember to select the "Always free" option, that does not asks you for a credit card. This is way more beginner-friendy than other clouds, such as AWS that don't allow a hard-limit on budgets.

Creating an ARM VM

Go to Compute > Instances

Push "Create an Instance", and a new dialog will appear.

First, you'll need to input a name for the instance.

Next, you can choose the OS image and the VM shape. I choose Ubuntu for this one, and also used Ampere ARM instance type, which you can max out to 4CPUs with 24GB of RAM!

You'll also need to setup the SSH keys you have, or if you prefer you can also create a new one. In this case, I'll use the keys I already have

Click Create, and the instance will start provisioning

Once your VM state is Running, connect to the instance through SSH, using your local terminal:

ssh ubuntu@${PUBLIC_IP}

First and foremost, let's update the packages already installed with the following commands



sudo apt update

sudo apt upgrade -y

Configuring code-server

Then, let's install code-server , which allow us to run vscode as a web server in this instance and connect from our local machines.

Copy the following into the remote session:

curl -fsSL [https://code-server.dev/install.sh](https://code-server.dev/install.sh) | sh

You'll see something similar to this in your shell:



Ubuntu 20.04.3 LTS
Installing v3.12.0 of the arm64 deb package from GitHub.

- Reusing ~/.cache/code-server/code-server_3.12.0_arm64.deb
- sudo dpkg -i ~/.cache/code-server/code-server_3.12.0_arm64.deb
(Reading database ... 112463 files and directories currently installed.)
Preparing to unpack .../code-server_3.12.0_arm64.deb ...
Unpacking code-server (3.12.0) over (3.12.0) ...
Setting up code-server (3.12.0) ...

deb package has been installed.

To have systemd start code-server now and restart on boot:
sudo systemctl enable --now code-server@$USER
Or, if you don't want/need a background service you can run:
code-server

After this, execute in your terminal:

code-server

this will create a default configuration and then start an HTTP server at port 8080. We need to make some changes to the configuration before code is ready to use.

Now, stop the running server with Ctrl+C, then open the configuration file to enable the self-signed TLS certificate, and also run in the default HTTPS port (443).

Open the ~/.config/code-server/config.yaml file, and perform two changes in this YAML file:

Change the cert field to true.
Change the bind-addr field to 0.0.0.0:443

Before starting the server, we need to give proper permissions for the server to run in port 443 and allow the incoming traffic from the internet.

Let's use the setcap command to allow this binary to use the privileged port 443, without running with complete root permissions.

sudo setcap cap_net_bind_service=+ep /usr/lib/code-server/lib/node

Then, we will enable the code-server service and start it.



sudo systemctl enable --now code-server@$USER
sudo systemctl start code-server@ubuntu

Verify that the service is now running

systemctl status code-server@ubuntu.service

Your console will print out something similar to this



● code-server@ubuntu.service - code-server
     Loaded: loaded (/lib/systemd/system/code-server@.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2021-11-15 23:41:32 UTC; 3min 46s ago
   Main PID: 34764 (node)
      Tasks: 22 (limit: 21304)
     Memory: 40.2M
     CGroup: /system.slice/system-code\x2dserver.slice/code-server@ubuntu.service
             ├─34764 /usr/lib/code-server/lib/node /usr/lib/code-server
             └─34783 /usr/lib/code-server/lib/node /usr/lib/code-server

Nov 15 23:41:32 vscode-remote systemd[1]: Starting code-server...
Nov 15 23:41:32 vscode-remote systemd[1]: Started code-server.
Nov 15 23:41:33 vscode-remote code-server[34783]: [2021-11-15T23:41:33.119Z] info  code-server 3.12.0 b37ff28a0a582aee84a8f961755d0cb40a4081db
Nov 15 23:41:33 vscode-remote code-server[34783]: [2021-11-15T23:41:33.121Z] info  Using user-data-dir ~/.local/share/code-server
Nov 15 23:41:33 vscode-remote code-server[34783]: [2021-11-15T23:41:33.144Z] info  Using config file ~/.config/code-server/config.yaml
Nov 15 23:41:33 vscode-remote code-server[34783]: [2021-11-15T23:41:33.145Z] info  HTTP server listening on http://0.0.0.0:443
Nov 15 23:41:33 vscode-remote code-server[34783]: [2021-11-15T23:41:33.145Z] info    - Authentication is enabled
Nov 15 23:41:33 vscode-remote code-server[34783]: [2021-11-15T23:41:33.145Z] info      - Using password from ~/.config/code-server/config.yaml
Nov 15 23:41:33 vscode-remote code-server[34783]: [2021-11-15T23:41:33.145Z] info    - Using certificate for HTTPS: ~/.local/share/code-server/localhost.crt

Configure the VNC Ingress rules

Even if the server is running, we're not able to access it from the external IP address, because of the firewall rules are not allowing the incoming connections.

Let's configure the network rules in order to allow connections to the running port.

Go back to Oracle Cloud web UI, go to Virtual Cloud Networks:

There is a vnc created by default, click on it and next click on the only subnet it has.

There is a section called Security Lists. Click on the only security list and next, click on Add Ingress Rules and configure the fields as displayed below:

This will allow any TCP connection for 443 port (HTTPS) from any IP address (that is what CIDR means)

Click again on Add Ingress Rules inside the dialog.

And after this, we finished the configuration for the server.

You can now use the public IP for your instance in your browser to connect to your VS Code web server:

https://PUBLIC_IP

You'll see a warning about a self-signed certificate. That is fine right now, because we don't have a public domain linked to this IP address, and code-server baked a self-signed one.

Go grab the password specified in~/.config/code-server/config.yaml inside the VM instance, and paste it in the password field.

Give it a few seconds and then you'll have a complete version of visual studio code running in your browser, with a VM up to 4 cores / 24 GB of RAM 🎉

Hope you find useful this guide, I'll keep posting other uses for your free tier Oracle Cloud, and hope this attracts more people that is starting in the cloud journey.

Universal macOS binaries with Go 1.16

Juan Carlos García Martínez — Sat, 20 Feb 2021 19:50:07 +0000

Go 1.16 adds support for the newest architecture in town, Apple Silicon. With the help of lipo, a tool included in XCode, you can create universal binaries, which can work in both classic x64 Intel processors and the M1.

Let's get started!

Requirements:

Go 1.16 or superior
XCode 12.2 or superior

Let's compile one of the simplest Go programs

package main

func main() {
    print("Hello,world")
}

Save this file in hello.go, and then execute the following two commands to generate binaries for both arm64 and amd64:

$ GOOS=darwin GOARCH=amd64 go build -o hello_amd64 hello.go 
$ GOOS=darwin GOARCH=arm64 go build -o hello_arm64 hello.go

The GOOS and GOARCH instruct the Go compiler to generate a binary for the given architecture and operative system. You can cross-compile and create binaries for Mac from Linux and Windows, but you won't be able to create universal macOS binaries (for now).

You can check the executable details of each generated binary with the file command:

$ file hello_amd64 
hello_amd64: Mach-O 64-bit executable x86_64
$ file hello_arm64 
hello_arm64: Mach-O 64-bit executable arm64

Ok, the next step is the magic: lipo merges the two executables into a Universal one:

$ lipo -create -output hello_universal hello_amd64 hello_arm64

And there it is! Now you have a universal binary, that can be executed in both platforms:

$ file hello_universal 
hello_universal: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
hello_universal (for architecture x86_64):  Mach-O 64-bit executable x86_64
hello_universal (for architecture arm64):   Mach-O 64-bit executable arm64

If you distribute macOS binaries, this might help you to improve the UX of your consumers, so they don't have to worry about which version should they use.

Hope this little post help you!

For more information:

Google Cloud Run 101

Juan Carlos García Martínez — Fri, 22 Jan 2021 18:16:55 +0000

Conoce Cloud Run y despliega una aplicación en la nueva plataforma de Google para contenedores.

¿Qué es Google Cloud Run?

Es una plataforma para ejecutar contenedores de forma totalmente administrada (aka serverless) que se ejecuta en Google Cloud, basada en knative y kubernetes.

Características de Cloud Run

Algunas de las características que hacen a Cloud Run una alternativa interesante son:

Puedes usar cualquier lenguaje de programación, librería o programas del sistema operativo, siempre y cuando esté empaquetado en un contenedor
Sólo pagas por el tiempo en que los contenedores atienden tu petición, si tu servicio no atiende peticiones, ¡Simplemente no pagas nada!
Puedes configurar el auto escalamiento de tus contenedores, para atender más peticiones on-demand
Provee auto-balanceamiento, redundancia, seguridad HTTPs por default, administración de logs y monitoreo
Tiene una couta gratis de 50 vCPU-horas al mes

¿Porqué elegir Cloud Run en lugar de Cloud Functions?

La otra solución de aplicaciones serverless de Google Cloud es Cloud Functions, la cuál permite ejecutar aplicaciones sin administración de servidores, pero sólo están disponibles para PHP, Python, Javascript y Go con el entorno de desarrollo de Google (SDK), así que el uso de librerías, versiones de lenguaje y dependencias está restringida por el entorno que Google mantiene.

¿Qué necesito para ejecutar contenedores sobre Google Cloud Run?

El punto clave de Cloud Run es que tu servicio web (HTTP o gRPC) funcionaría sin modificaciones, siempre y cuando respete las condiciones de ejecución:

El CPU está activo mientras procesa una petición HTTP, es decir mientras el contenedor esté en ejecución pasiva (sin atender peticiones), prácticamente no tendrá acceso al CPU.
El acceso al sistema de archivos local es limitado, todo archivo que se escriba por tu aplicación se cargará en memoria RAM del contenedor.
Está diseñado para ejecutar contenedores stateless

Para conocer todas las características podemos ver los detalles en la siguiente liga

¡Ahora vamos a hacer nuestro primer despliegue en Cloud Run!

¡Manos a la obra!

Para desplegar nuestro servicio en Cloud Run, vamos a desplegar una aplicación disponible en este repositorio de Github

Para este tutorial vamos a usar una cuenta de Google Cloud (no te preocupes, está dentro de la cuota gratuita), Docker y algún cliente para consumir servicios HTTP

Como podemos ver en el archivo Dockerfile del proyecto, construye una aplicación en Go que comprime imágenes jpg, levantando un servidor HTTP escuchando en el puerto especificado de la variable de entorno $PORT.

FROM golang:1.14-alpine as builder
WORKDIR /opt
COPY . /opt
RUN go build .

FROM alpine:3.11
RUN addgroup -S webgroup && adduser -S appgroup -G webgroup
USER appgroup
WORKDIR /opt
COPY --from=builder /opt/cloud-run-example .
ENV PORT
ENTRYPOINT [ "/opt/cloud-run-example" ]

Para desplegar el servicio vamos a acceder a Google Cloud, y usar un proyecto existente o crear uno nuevo.

Una vez tengamos un proyecto, vamos a abrir Cloud Run y configurar un nuevo servicio:

Ubicamos la sección de Cloud Run

Y creamos un nuevo servicio

Ahora llenaremos el siguiente formulario

En el formulario ingresaremos el nombre cloud-run-101, y la región en la que se ejecutará el servicio.

En la sección de autenticación eligiremos que el servicio permita peticiones sin autenticar. Al montar el servicio en producción deberíamos usar algún método de autenticación, ya sea integrado en el servicio o usando Cloud IAM.

El ayudante de Cloud Run nos solicita una imagen de Docker, la cual subiremos a continuación

Para desplegar la imagen que usaremos en nuestro repositorio privado de imágenes, abriremos una sesión de Cloud Shell y escribiremos el siguiente comando:

docker pull wraven/cloud-run-example:latest

Con el fin de descargar la imagen a nuestro repositorio de docker local. Lo que haremos después será re-etiquetar la imagen para subirla a nuestro repositorio privado. Por ello usaremos el id del proyecto, el cual obtendremos revisando el apartado de proyectos.

En esta sección encontraremos el id del proyecto

Pondremos el id del proyecto como una variable en nuestra terminal, etiquetaremos de nuevo la imagen para subirla a nuestro repositorio privado.

export PROJECT_ID=<tu-proyect-id>
docker tag wraven/cloud-run-example gcr.io/$PROJECT_ID/cloud-run-example:1.0
docker push gcr.io/$PROJECT_ID/cloud-run-example:1.0

¡La imagen ya se puede utilizar en Cloud Run!

Vamos a ingresar el tag de la imagen en el asistente y después pulsaremos Crear

Este es el último paso y habremos creado el servicio de Cloud Run

Después de esto, veremos una pantalla donde se estará desplegando el servicio y nos dará una URL donde podremos consultarlo cuando esté disponible.

Esta es la pantalla de información para nuestro servicio de Cloud Run

Estas son algunas propiedades relevantes sobre nuestro despliegue:

Propiedad	Valor	Descripción
CPU asignada	1	vCPUs asignados al contenedor
Memoria asignada	256 MB	Memoria RAM asignada
Simultaneidad	80	Peticiones concurrentes que puede atender cada contenedor
Tiempo de espera de solicitud	900 second	Tiempo máximo de respuesta

También podremos ver la URL del servicio desplegado, donde ya podemos procesar peticiones, similar a esta:

URL: https://cloud-run-example-bcexihr6qaff.a.run.app

Si consultamos el servicio en un navegador, obtendremos una respuesta en JSON:

Nuestro servicio ya está disponible y listo para usarse

Ahora vamos a probar su funcionalidad. Para este servicio requerimos enviar una imagen JPEG y un parametro en
la url calidad con el valor (0-100) de la calidad en la que queremos obtener la respuesta.

Probaremos usando Postman adjuntando una imagen a la petición POST.

Se especifica el párametro URL calidad con el porcentaje de calidad que se desea obtener. Al enviar la petición obtenemos una imagen con menor tamaño

Podemos probar con distintas imágenes y calidad para probar el funcionamiento del contenedor. Ahora, en la
pestaña de registros podemos ver los logs del servicio.

Los logs del servicio que se imprimen en la salida estándar se verán en este apartado

Vamos a desplegar otra versión del servicio para ajustar la configuración. Seleccionemos la opción
Editar y desplegar una nueva revisión.

Ajustaremos el tiempo de respuesta a 300s, la memoria RAM a 128 MB y el máximo de 4 instancias

Marcaremos Servir esta revisión de inmediato y pulsamos desplegar

Después de unos segundos que inicie el contenedor, podremos ver la información de la nueva revisión.

Los detalles muestran la información de nuestra segunda revisión

Despliegues instantáneos con un sólo click

Después de hacer el proceso de despliegue manual, vamos a probar desplegando el mismo servicio usando un Cloud Run Button.

Vamos al repositorio de ejemplo y pulsemos sobre el botón Run on Google Cloud

Usaremos Run on Google Cloud para desplegar el servicio de manera más sencilla

Nos mostrará un mensaje informativo sobre lo que sigue a continuación: Clonará el repositorio, construirá la imagen de Docker con la información del Dockerfile

Ahora en una ventana de Cloud Shell, se mostrará el detalle del despliegue con algunas preguntas

Primero se revisa el proyecto de Google Cloud donde se construirá el servicio

Se construye la imagen de Docker dentro de Cloud Shell

La sube al registro de Docker privado e inicia el despliegue. Veremos el detalle del servicio, la URL desde la cual es accesible y el panel de administración para revisar los detalles

Si ejecutamos el servicio a esta nueva URL veremos que también funciona

Gracias a Cloud Run Button en el repositorio de Github y el Dockerfile configurado en él, fue más rápido desplegar el mismo servicio

Limpiando todo

Volvamos a la sección de Cloud Run para eliminar el servicio que creamos,
después abriremos una terminal de Cloud Shell para borrar las imágenes construidas de nuestro registro privado.

Eliminamos el servicio desde Cloud Run, nos pedirá una confirmación, y Aceptamos pulsando Eliminar

Vamos al Shell para eliminar las imágenes que existen en el repositorio privado

El comando para eliminar las imágenes es el siguiente:

gcloud container images delete gcr.io/$PROJECT_ID/cloud-run-example

¡Espero te haya gustado la publicación! Comparte tus dudas o comentarios aquí :)

Para más información

Consulta las ligas oficiales de Cloud Run y algunos ejemplos prácticos: