Desde mi Hamaca

From PHP to Rust: Migrating a REST API between these two languages. (Part I)

Raul Castellanos — Thu, 29 Dec 2022 14:16:46 GMT

Disclaimer

Before beginning, I want to say that I'm a huge fan of PHP for several years. This not only allowed me to create great applications but also keeps the food on my table <3.

However, Rust is gaining traction among the developer community. It's not for nothing that it's the most loved programming language in the last 7 years in Stackoverflow's Developer Survey (details here). With this blog post, I want to try and show you the difficulties for a PHP developer to learn Rust with a practical example: the migration of a single API endpoint from PHP to Rust.

What's RUST Language

Originally made as a C-Language replacement, Rust rapidly evolved not only to build software systems (operating systems, IoT, and AI) but with the big community, the web frameworks begin to grow in the ecosystem

Why Rust:

Blazingly fast and memory-efficient. With no runtime or garbage collector, it can power performance-critical services
A strong typed system and ownership model that guarantees memory-safety and thread-safety programming, enabling you to eliminate many cases of bugs at compile-time
Great documentation, a friendly compiler with useful error messages, top-notch tooling and much more.

The most known web framework is called Actix-Web (more here) , and it is considered one of the most performant web frameworks available on the market, capable of serving 552K requests per second. (the benchmark can be viewed here)

The Application

If you read my previous blog post, I always have a "demo application" to use in all my tutorials: the "Availability API". This application is far from simple but it contains the implementation of a minimum web application nowadays (Rest API, DB Access, Hexagonal Architecture design, etc).

The architecture of the infrastructure is not important here but since we use a k8s cluster agnostic, we can reuse it here for demonstration purposes.

The Migration

As the first step, we want to write the web server and configure the web server using the actix-web framework. This will include setting the routing and the controller to receive and respond to requests.

File Structures

As we said before, the availability API was designed with a hexagonal architecture in mind, so we want to reach the same goal using Rust. Let's see how it compares with PHP.

Rust `main` entrypoint

In Rust you use main.rs. This is equal to bootstrapping in PHP. In this file, you have a main() function, which is mandatory for any Rust application to work just like Java or Typescript Main.

Here how my main.rs the file looks like. Remember, that I'm using using actix-web framework, so the "bootstrapping" of the web server will be through the actix-web framework.

You also have the availability-controller. This will ask third party API's and databases if it's available.

Note that PropertyAvailabilityRequest is a DTO with a series of ValueObject that validates itself, so in case of an invalid request body, and serialized JSON error is returned to the client.

Compile and Run

Now let's compile and try to run this first step:

cargo build && cargo run

Now we're ready to test our first very basic endpoint, the response must be equal to the request that we send to the API.

curl --location --request POST 'http://localhost:8080/v1/property/availability' \--header 'Content-Type: application/vnd.api+json' \--header 'Accept: application/vnd.api+json' \--data-raw '{  "requestDates": {    "checkin": "1956-06-29T02:09:38.752Z",    "checkout": "1977-01-17T15:39:47.465Z"  },  "pax": [    {      "adults": 2,      "childs": 1    }  ]}'

And at least for this first part, we can migrate an endpoint from PHP to Rust. We have a lot of work to do regarding the database connection, event dispatching and other kinds of stuff. In the next chapter, we will add some kind of middleware to add custom headers, database connection and so on.

Thank you for reading!

Support Me

If you like what you just read and you find it valuable, then you can buy me a coffee by clicking the link in the image below.

]]>

Managing database migrations safely in high replicated k8s deployment.

Raul Castellanos — Sun, 13 Nov 2022 12:49:04 GMT

So, you want to run migrations in a cloud native application running on a Kubernetes cluster, and don't die trying huh!

***Well you're in the right place!! ***

After I break some applications in terms of database migrations in a multi replica and concurrent deployment process, I want to give you some advices based on my faults, on how you can run you migrations in a safely way, with native k8s specs and without hacks of any kind. (no helm, no external deployers, pure and plain k8s process well orchestrated)

The Problem

Is very common, modern application evolves faster, new features arise from product to satisfy the final user, and with every new deploy is too common the need to alter your database in some form and you have, many tools to allow you to manage the execution of the migrations against your database, BUT, not when they occur.

If you have an application pod, let say with 4 replicas, and you deploy it, the all 4 will try to run the migrations at the same time potentially causing data corruption and data loss, and nobody wants that.

When to run migrations `(the workflow)`

In the old-way of run migrations we used to have something like this:

Put the application in maintenance mode (divert traffic to a special page)
Run database migrations
Deploy new base code
Disable maintenance mode on application

Obviously, this isn't acceptable approach if you want to achieve zero-downtime deployments in the actual always-on world, we need to achieve (at leats) the following steps to assure that migrations and application run in a safety way.

Run migrations while the old version of the application is still running, and do the rolling update "only" when migrations are successfully run.

Something like this:

`Job`, `InitContainer` and `RollingUpdates`

So after choose our strategy to run migrations on k8s, we need to write our manifests in order to accomplish the defined workflow.

First, the migrations job itself:

apiVersion: batch/v1kind: Jobmetadata:  name: availability-api-migrationsspec:  ttlSecondsAfterFinished: 60  backoffLimit: 1  template:    spec:      containers:        - name: migrations          image: availability-api-migrations          command:            - '/bin/sh'            - '-c'            - ' bin/console doctrine:migrations:migrate --no-interaction -v'          envFrom:            - secretRef:                name: protected-credentials-from-vault      restartPolicy: Never

Now in the deployment manifest of the application we need to defined 2 things very important to allow our workflow work as expected.

The rolling update strategy
the init container and command to forbid deployment init until migrations are done.

apiVersion: apps/v1kind: Deployment...spec:  ...  strategy:    rollingUpdate:      maxSurge: 25%      maxUnavailable: 0   template:      spec:        initContainers:          - name: wait-for-migrations-job            image: bitnami/kubectl:1.25            command:              - 'kubectl'            args:              - 'wait'              - '--for=condition=complete'              - '--timeout=600s'              - 'job/availability-api-migrations'

What is the meaning of that snippet above:

RollingUpdate strategy:
- The rolling update allow us, to define the strategy on how many pod replicas we want to update with the new code at a time (you can also choose between other k8s strategies like recreate, blue/green or canary)
InitContainer migration job watcher
- Now we want, to forbid in some way that the rollout deployment begins until the migrations job was finished in completed status. Fortunately the kubectl cli tools allow us to ask and wait the status of k8s component, we use that advantage of the kubelete api to use here, and "block" in some way the deployment

$kubectl wait --for-condition=complete --timeout=600 job/availability-api-migrations

We wait for the job availability-api-migrations status complete with a timeout o five minutes, the kubectl will ask permanently until timeout was reach. Obviously if the migration job finish in there milliseconds, automatically the wait loop ends and allow the deploy to begin otherwise, the deploy will fail. The timeout is the MAX allowed time to wait for ask for complete status on a job.

At least with this we can assure that data consistency is preserve, but it's importan follow some guidelines in terms on how to write and deploy migrations in you applications, below we'll cover that.

Safety recommendations

Write your migrations always thinking in a fast execution, if you expect to run migrations that took more than 5 minutes, considering ask for a maintenance window to restrict traffic access to the application.
Do your migrations always thinking in retro compatibility of your current code running on production.
For example, do not alter a table adding a column NOT NULLABLE or without DEFAULT value.
If you need to add a column and delete other, the best strategy to follow is to do 2 separates deployments.
- Run the first deploy adding the column, and validate that all is running smoothly in production.
- Run a new deployment only deleting the old column from the database.

Support Me

If you like what you just read and you find it valuable, then you can buy me a coffee by clicking the link in the image below, I would be appreciated or you can become an sponsor :).

]]>

How to build a CI/CD workflow with Skaffold for your application (Part III)

Raul Castellanos — Wed, 09 Nov 2022 09:06:04 GMT

🔥 This is third part (and last) of the series "Full CI/CD workflow with Skaffold for your application".

Let's recap: `The Workflow`

This is the workflow so far:

📣 You can check how to get to this point in the firsts two delivery of the series.

Gitlab `K8s agent` and Security

This main part in the integration of k8s and Gitlab with the Gitlab K8s Agent, is, in my experience, the best and easy way I find to integrate K8s with a DevOps platform like Gitlab.

Let's recap some steps

You need to add an Agent and them run a helm chart into your cluster to allow the secure communication between both.
the agent can be configured in 2 ways:
- CI_ACCESS: Allow access from the project repository pipeline to the cluster and then you are in charge to manage how to deploy in the cluster.
- GITOPS_ACCESS: This allow a full gitops flow like ArgoCD for example, updating your cluster in a pull based way in sync with the main branch of the repository.

In my case a use the first one CI_ACCESS since I want to manage in a more granular way, the whole process with skaffold, so mi configuration is way simpler

I have 2 repositories in a application group, one for the micro service itself and one for the agent (the agent also could be put in the micro service repository, but if you want more granular access or share the agent/cluster between applications of the same stack, this is the best way)

So in the K8s-agents repository, we only have the declarative config.yaml file for every agent that we want to create (for this example I have 2, one for lower-envs/runner and one for production since they are 2 different clusters)

And in the config itself, I give access to all the projects that I want to use in the cluster.

And last, bit no least, the need to link the agent with the cluster, for that, you should go to the k8s project, Kubernetes Cluster menu, and there you will see an interface where you will receive the instructions on how to link agent/cluster via a helm chart to be installed in the cluster.

After that, you cluster and gitlab instance are now linked, and you applications can use the cluster as Kubernetes-Executor runners and also for dynamic review environments (aka dynamic QA instances to say so)

Deployment and Safety Recommendations for `K8s Agents`

To restrict access to your cluster, you can use impersonation. To specify impersonations, use the access_as attribute in your Agent's configuration file and use K8s RBAC rules to manage impersonated account permissions.

You can impersonate:

The Agent itself (default) = The CI job that accesses the cluster
A specific user or system account defined within the cluster

Impersonation give some benefits in terms of security:

Allows you to leverage your K8s authorisation capabilities to limit the permissions of what can be done with the CI/CD tunnel on your running cluster
Lowers the risk of providing unlimited access to your K8s cluster with the CI/CD tunnel
Segments fine-grained permissions with the CI/CD tunnel at the project or group level
Controls permissions with the CI/CD tunnel at the username or service account

Provisioning cluster with `terraform`

As I said, the main goal of this tutorial is try to get the same tooling for local development, pipeline and deployment, but (always got a but), we have 2 sets of the terraform configuration instructions, of example for local development I want, as developer, to get as much of the observability tools that I have on production, in case I need to test metrics, build dashboards on grafana, etc, but without the complexity of production infrastructure architecture.

So in this case, we can give the application diagram for the first part here, as recap of 'how our local development stacklooks like, and how to achieved withterraform `.

So, for this application structure, i want to get in my local environment the cluster and it's 'pre-requisites' for my architecture, understood as pre-requisites all the others components inside the cluster that no belongs to the application itself (monitoring stack, traefik, cert-manager, etc).

So for that, I write simple modules to install that dependencies inside the local cluster, and get them available to use when a run my application locally with skaffold.

My structure for infrastructure folder looks like this:

Every module has inside their main.tf configuration file setting the desired state for my cluster after it's applied.

Lets take a look for one of this module (prometheus) main file:

terraform {  required_providers {    kubernetes = {      source  = "hashicorp/kubernetes"      version = ">= 2.13.1"    }    helm = {      source  = "hashicorp/helm"      version = ">= 2.7.0"    }    kubectl = {      source  = "gavinbunney/kubectl"      version = ">= 1.14.0"    }  }}resource "kubernetes_namespace_v1" "monitoring_namespace" {  metadata {    name = var.monitoring_stack_namespace  }}resource "helm_release" "prometheus_stack" {  name  = var.monitoring_stack_prometheus_name  repository = "https://prometheus-community.github.io/helm-charts"  chart = "prometheus"  version = var.monitoring_stack_prometheus_version_number  namespace = var.monitoring_stack_namespace  create_namespace = false  values = [    file("${path.module}/manifests/prometheus-override-values.yaml")  ]  depends_on = [    kubernetes_namespace_v1.monitoring_namespace  ]}resource "kubectl_manifest" "prometheus_stack_ingress" {  yaml_body = file("${path.module}/manifests/prometheus-ingress.yaml")  depends_on = [    helm_release.prometheus_stack  ]}

And then, in the root main.tf configuration file, you can wrap as many modules as you want, for my case, with my 4 modules was enough (prometheus, traefik, cert-manager, grafana)

module "cert_manager_stack" {  source = "./module/cert-manager"}module "traefik_stack" {  source = "./module/traefik"  depends_on = [    module.cert_manager_stack  ]}module "prometheus_stack" {  source = "./module/prometheus"  depends_on = [    module.traefik_stack  ]}module "grafana_stack" {  source = "./module/grafana"  depends_on = [    module.prometheus_stack  ]}

This also, has a handy target in our Makefile, allowing developers and operators, easily setup and remove cluster pre-requisites

Setup the pre-requisites took about 3 minutes, but if something that you need to do, time to time, you can setup your cluster today, work on your feature for some days, and then shutdown.

After all this, you will have a fully functional Local-To-Prod pipeline. (if you need to see how the Gitlab CI file looks like, is in the second part of this series)

This is the las delivery of the series, but now I'll write about the others tools that i use to address different challenges in my day to day work.

If you are interested the next topics I'll write on are:

Managing database migrations at scale in Kubernetes for PHP application with symfony/migrations component
Istio, Cert-Manager and Let's Encrypt: Secured your k8 clusters communication with automated generation and provisioning of SSL Certificates
Internal Developer Platform: A modern way to run engineering teams.
The Digital War Room or how to get observability for Engineering Managers across applications and teams.

Support me

If you find this content interesting, please consider buying me a coffee :')

]]>

How to build a CI/CD workflow with Skaffold for your application (Part II)

Raul Castellanos — Mon, 07 Nov 2022 08:45:42 GMT

🔥 This is the second part of the series "Full CI/CD workflow with Skaffold for your application".

Lets recap the `Workflow`

As you remind - and if not, you can read the first release of this tutorial 😅 - my main idea is to implement one tool - skaffold - as a building block for my CI/CD workflow, who should be managed by a single makefile as entrypoint for local development and pipelines - on gitlab - and all this should be deployed in a K8s cluster in GCP

And also, for the simplicity of this tutorial, we use the image and artefact repository in the same gitlab SAAS, but you can use whatever you want for this task (Amazon S3, Docker Registry, Private Registries, Azure Object Storage, etc)

This is the workflow so far:

📣 The tool setup and local workflow were covered in the first delivery of this tutorial.

The Makefile

As said, the makefile, is, the main entrypoint for commands to be executed by developers when they do development work locally, and for gitlab pipelines in their different stages (must vary on your implementation), and that makefile commands mostly are wraps for skaffold ones, with the difference, that i need to pass dynamic values to those stages to work I expect to, so it's better to wrap then in a makefile target that received that dynamic params and then run the 'skaffold' command itself. (later you will now why)

As for the time I was writing this article, my targets are:

Hopefully for local development we have an unique command since skaffold run do the full pipeline cycle (build, test, deploy, hot reload) for development , so, why then i need to wrap this single command in a makefile target?, mostly because I need that this work no matter what type/kind of local cluster technology the developer use (docker-desktop, Minikube, etc) and no matter what OS developer machine was (MacOS, *Nix) and for that, I need to pass the kube-context parameter to skaffold that in my case is docker-desktop (since docker desktop already bring me a pre installed k8s cluster for local development and that free me to the need to install manually a cluster in my machine - a win for docker-desktop here -.

So you will encounter that the majority of the makefile wraps, come in the form of rehuse the same command in multiple stages (pipelines) based on the received parameter in the make execution, and also, generating random seeds to prefix namespaces (because you will have more than one developer working in the same code base at once) and I want to avoid collision between gitlab pipelines and deploys in lower environments when N developers are working in the same code base.

We must focused in pipeline target ones (all of then with skaffold tool), since the infrastructure ones, related to install prerequisites in local cluster to comply with the architecture design, isn't cover in this series, but in the another series that 'll wrote in next weeks)

Here is how my makefile looks at the time of writing this article, and for those stages (because in technology everything evolves quickly I always remind this 😅)

#------ Development and Pipeline targets ----------#run:    ## DEVELOPMENT[skaffold]: Up and running stack in development mode with hot reloading in the local machine    @$(MAKE) _requirements    @skaffold dev -f $(DEPLOY_DIR)/skaffold.yaml -p development -n $(PROJECT_NAME) --no-prune=false --cache-artifacts=falseunit:    ## DEVELOPMENT[skaffold]: build, deploy and run unit tests => FOR PIPELINE: `make unit profile=pipeline kube_context=cluster-gitlab-context`    @$(MAKE) _run_test_suite SUITE=unit PROFILE=$(PROFILE) NAMESPACE=$(DYNAMIC_NAMESPACE) KUBE_CONTEXT=$(KUBE_CONTEXT) || $(MAKE) _cleanup KUBE_CONTEXT=$(KUBE_CONTEXT) PROFILE=$(profile) NAMESPACE=$(DYNAMIC_NAMESPACE)integration: ## DEVELOPMENT[skaffold]: build, deploy and run integration tests => FOR PIPELINE: `make integration profile=pipeline kube_context=cluster-gitlab-context`    @$(MAKE) _run_test_suite SUITE=integration PROFILE=$(PROFILE) NAMESPACE=$(DYNAMIC_NAMESPACE) KUBE_CONTEXT=$(KUBE_CONTEXT) || $(MAKE) _cleanup KUBE_CONTEXT=$(KUBE_CONTEXT) PROFILE=$(profile) NAMESPACE=$(DYNAMIC_NAMESPACE)functional: ## DEVELOPMENT[skaffold]: build, deploy and run functional tests => FOR PIPELINE: `make functional profile=pipeline kube_context=cluster-gitlab-context`    @$(MAKE) _run_test_suite SUITE=functional PROFILE=$(PROFILE) NAMESPACE=$(DYNAMIC_NAMESPACE) KUBE_CONTEXT=$(KUBE_CONTEXT) || $(MAKE) _cleanup KUBE_CONTEXT=$(KUBE_CONTEXT) PROFILE=$(profile) NAMESPACE=$(DYNAMIC_NAMESPACE)build:    ## PIPELINE[skaffold]: build and push images to registry => `make build tag=1.0.0|71dcab00 kube_context=docker-desktop`    @skaffold build -f $(DEPLOY_DIR)/skaffold.yaml -p production -t $(tag) --kube-context=$(kube_context) --file-output=pipeline-artifacts.jsonrender:    ## PIPELINE[skaffold]: render manifests and push to artifact registry => `make render namespace=availability tag=1.0.0|71dcab00`    @skaffold render -f $(DEPLOY_DIR)/skaffold.yaml -p production -n $(PROJECT_NAME) -a pipeline-artifacts.json -o $(PROJECT_NAME)-api-$(tag)-production.yamldeploy:    ## PIPELINE[skaffold]: apply hydrated manifests to desired namespace on cluster `make deploy tag=1.0.0|71dcab00 profile=production namespace=availability kube_context=docker-desktop`    @kubectl create namespace $(namespace) --context=$(kube_context)    @skaffold apply -f $(DEPLOY_DIR)/skaffold.yaml -p $(profile) -n $(namespace) --kube-context=$(kube_context) --status-check=true $(PROJECT_NAME)-api-$(tag)-production.yaml || $(MAKE) _cleanup KUBE_CONTEXT=$(kube_context) PROFILE=$(profile) NAMESPACE=$(namespace)

As you can see, all targets are warps for skaffold, but, allowing me to pass dynamic data, context and profiles (we'll look this in the skaffold file explanation below), the complete file is more larger, but with this snippet you can get an idea on how you can build something like that.

The `skaffold` file

The main workflow orchestrator has a main config file, when we can define, how the application should be builded, tested, render their manifest and deployed, so it's a vertebral part of this strategy, and now I'll explain you mine.

I have two skaffold profiles: one called development and the other production, and a common part share between them like tag strategy, deploy strategy, and both of them use the same Dockerfileto build their images pointing to the correcttarget`. (You can use separate Dockerfiles, but in my case I want to maintain as simple as possible because the difference between 2 images dependencies are minimum)

the skaffold fiel lives inside my deploy folder (do you remember my file organisation? You can re-checked in the first delivery of this series), and all the deployment related files are store there.

As you can see the skaffold.yaml file is in the root of the deploy folder since is my main workflow orchestrator, in the other folder we have the main k8s manifests and inside overlays we have the yaml patch's for every profile (most of the cases the same as an environment) that we want to declare.

The `.gitlab-ci.yml` Pipeline

Since I use trunk base development strategy in micro services, we need to design 2 flows of pipelines, one for features branches and one for main branch, additionally to that, to be able to reach production we first need to tag a commit, so that's the real trigger for Go-To-Prod Pipeline.

Feature Branches Workflow (trigger by merge_request commit):

In this stage, the developer needs to be able to:

Run all tests suites
Build and Image with production dependencies
Deploy to a dynamic namespace in the same cluster where pipeline runs (a Dynamic QA to say so, allowing to every developer to have "their own" QA server while their are working on a feature)
Destroy the dynamic deployment (remove review app and namespace)

Looks like this:

Also we use gitlab environments to see in the Gitlab UI "what's is deployed in what environment", and also to visualise production and stages latest deployment status and artefacts.

So, when a new "dynamic QA" environment is deployed, you'll see this in environment page of your project:

And also on the MR View on Gitlab you'll see in what "review" environment is deployed that MR.

Main Branch Workflow (trigger by a TAG):

In this stage, the developer needs to be able to:

Run all tests suites
Build and Image with production dependencies
Create a Release Package (this a gitlab feature like Github to display release contents in a special page on gitlab)
Deploy to Production

Looks like this:

The main workflow has 3 stages more, including deploying to staging cluster/namespace, but more important has the creation of the release package and the deployment to production.

The only manual job is deploy to production.

Gitlab Release

Production Environment after Deployment

All the best of all, all this is DONE automatically via the automated Pipeline on Gitlab. You can view the skeleton of the pipeline in this Snippet:

https://gitlab.com/playground-arena/api-symfony-roadrunner-cqrs/-/snippets/2448780

BONUS: `Kaniko` image Builder

Since version 1.24, Kubernetes was moving away from dockershim as container runtime, so I want a solution that:

Allow me to build container inside a K8s cluster
Continue to writing Dockerfiles as today
Not need to share or mount a socket into a pod (that's the main security reason to not use docker)

So I discover the last year Kaniko, this is another tool on the Google Container Tools on Github, that allows us to build an container image from a Dockerfile without Docker. Marvellous.

It has som benefits:

*Kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. (no need to mount a docker socket anymore)

Provides a handy docker image to use in pipelines (a very light weight one, so your jobs doesn't take much time to run)
Provides a Caching system in the same repository where the images are stored, so in every job that tries to build the image, Kaniko will check first the repo cache layers and downloaded speeding up the build job.

When a build a image I check my repo and I can see the caching layers separated from the final images (see image below)

Cache Layers

Builded and Tagged Images

Deployment safety considerations

All in life has it's tradeoff, and this isn't the exception, however, is possible to joint team autonomy with security and governance, no only with this example, but in general in software development.

Some of my personal recommendations on this are:

Secrets: Always use a secret vault (in my case i use Hashicorp one)
Fine-grained permissions control with the CI/CD tunnel via impersonation and k8s agent:
- Allows you to leverage your K8s authorization capabilities to limit the permissions of what can be done with the CI/CD tunnel on your running cluster
- Lowers the risk of providing unlimited access to your K8s cluster with the CI/CD tunnel
- Segments fine-grained permissions with the CI/CD tunnel at the project or group level
- Controls permissions with the CI/CD tunnel at the username or service account
Make your high environment namespaces immutable (on K8s namespace creation time)
Fine-Grained RBAC on Gitlab Roles (I think this isn't available on the Free and Self-Managed versions)

Next Chapter

In the next chapter I'll wrap up all things that we cover in the first 2 releases of the series in a fully functional pipeline from local to production with a small k8s cluster and I expect, that you can see all the work in action and some final remarks to allow you to test in your projects.

Thanks for reading!

Support me

If you like what you just read and you find it valuable, then you can buy me a coffee by clicking the link in the image below.

]]>

How to build a CI/CD workflow with Skaffold for your application (Part I)

Raul Castellanos — Mon, 31 Oct 2022 20:39:26 GMT

Skaffold (part of the Google Container Tools ) was on the market since 2018, but was in 2020 when, (at least for me), they reach a prod-grade maturity level on the tool.

And I was more than fascinated on how, this tool not only can facilitate the developer work on local machines, but also, as a complete pipeline from development to production environment, if is used with a couple of other tools.

Easy and Repeatable Kubernetes Development, no matter if you are a developer, lead, platform engineer, SRE or head of Engineering, all we're agree on that 🙋🏽.

We want an easy, repeatable, reproducible development workflow, that brings more autonomy in the teams, to bring more product value to the final user in a secure way.

I want to show you, how I use Skaffold as building-block for my micro service CI/CD pipeline from local to production.

The Toolset

skaffold cli (you can use the provided docker image or install in you machine)
kubectl and Kustomize (kustomize is part of kubectl cli already)
K8s cluster (local and remote) - if you use docker-desktop you've already one cluster installed by default, to use for local development.

Isn't intended in this article to show, how to install a k8s cluster for local development, you have various alternatives like Minikube out there. Like I said, I my case since I use docker-desktop and they come with a k8s inside by default, is easier to me and for the development experience to work on this way, however if you don't use docker desktop, you could use any of the others alternatives available in the market.

The Workflow

The main idea is, to use 'skaffold' as a building block from local to production environment, simplifying the tooling used by the developer and facilitating the integration with the actual gitlab repository service.

The more complex part would be, the integration and functional tests, since integration and functional tests needs the complete application and dependencies running, a little more work needs to be done to accomplish that, however isn't as complex as sounds, since I used a Kubernetes gitlab runner to run the pipelines, so, we can use the same runner to deploy the application in a special namespace, run our tests, and then, remove the application from the runner.

Be aware, that you need to do a cleanup process after each pipeline or stage run, to avoid left running process consuming capacity and space in your Kubernetes cluster and to avoid recurring in unexpected operational costs.

The Application

It's the simplest micro service you may know, but it's intended for demonstration purposes. Was made in Symfony with RoadRunner as application server, expose metrics to a prometheus metrics server, and then this metrics are fetched from the monitoring stack to be used in grafana dashboard for monitoring and observability purposes.

Now, that we have all the context clear, lets begin with the next steps: first at all, i need to setup our repository skeleton and directory structure, in order to be, as functional as possible to my intended workflow and development process.

Take into account, that this, is how I setup my repositories, and you should fit this to your expectations and operational workflow.

Additionally, my principal goal when I began to work with this GitOps approach was also: reduce the cognitive load and operational complexity for new an current colleagues, reducing also the onboarding time and the number of tools that we need to do our work.

If you need a more complex scenario for metrics scaling, i normally try to use thanos for that job, since allows me to easily scale prometheus, and get long term storage in commonly knows cloud object storage services, like Amazon S3 or GCP Cloud Storage.

Below you can find a diagram of the same application but implementing thanos.

Let's continue this guide with the simplified version of the application (the one with only prometheus and Grafana components for monitoring)

Folder Structure and Orchestration process

Lets recap on some concepts about the tooling that we're implementing here, to fulfil the promise of a, full workflow with skaffold from local to production.

I deploy on K8s cluster with kubectl and kustomize (kustomize is part of k8s bundle).
I use skaffold as workflow building block through their cli command steps (build, test, render, deploy, verify)
I build images locally with docker cli (is a pre requisite for my workflow) and in gitlab i have a couple of options alongside docker (Kaniko or Docker in Docker variations), but i'll cover that in the next steps.
I use a Makefile as command "collector" entrypoint no only for local development but for gitlab pipeline to group commands in single word ones (make run, build, unit, etc).
I use terraform declarative configuration files, to set the desired state of my working cluster (in that case the local one), in this desired state we have some pre-requisites needed in my architecture definition, like cert-manager, traefik, prometheus and grafana, like my machines on staging and production.

* deploy/    manifests/  # the place where k8s yaml resides         - *k8s.yaml         - kuztomization.yaml    overlays/ # for every environment that you want, you should have an overlay        development/              - *.k8s.patch.yaml              - kuztomization.yaml        production/             - *.k8s.patch.yaml             - kuztomization.yaml   - skaffold.yaml* infrastructure/ #terraform scripts to install cluster pre requisites vault, cert-manager, treafik* src/ # all the source code of your application    - Dockerfile - Makefile- .gitlab-ci.yaml

Another important component of this setup is: the Dockerfile, to be able to use the same dockerfile to build images for development and production environments (with the dependencies of each of them), I build a multi-stage dockerfile that allows me to get a target for development, and a target for production, that we can point to in the skaffold build phase.

Kustomize files, (kustomization.yaml ones), allow me to declare a patch or merge of the part of the main k8s manifest, to apply the changes that I need to change in some environment without the necessity of duplicating the entire YAML, so, for example, if I have the following k8s manifest declaring an API with 1 replica, and then, I can declare a patch to set that number to 4 replicas if the environment is in production.

The following image shows you, how is a main k8s manifest and their corresponding patch for production. You can patch anything you want, adding all the data, metadata and other labels to every manifest in environment overlays.

Then, we have our skaffold file, in charge of the orchestration process of the workflow itself:

Since skaffold allows us to use kustomization as a deployment strategy, I organise my profiles to do so, and also, with this, the development team has a lot of manoeuvres to modify and deploy changes with zero effort.

Now, I can run everything in one shot to see how this work, so, it's everything is ok, I'll capable to access all the tools (via browser) and the API requesting them.

To run skaffold you need to run the following command: skaffold dev -p development, but since we use a Makefile as a command entrypoint, you can see above that make run do the same job as we need to run skaffold in development mode.

I use my domain and a self-signed certificate to access, all applications via a FQDN over HTTPS (using cert-manager and traefik for that), now, I'll be able to access all of them via that URLS (on the local machine this URLs points to the loopback 127.0.0.1 in the /etc/hosts file)

We should have at least these applications:

Grafana
Traefik Dashboard
API /Application

Let's see in this animated GIF, those applications running:

😅 with this, i already have a full local development cycle for my local environment, now the next milestone is, to make my

gitlab pipelines compliance with this pipeline and make the way to Low and Prod environments.

Let's stop here for now. I'll prepare the material for the next blog entry.

Next Chapter

In the next chapter of this tutorial, I'll try to implement this local workflow in GitLab pipeline, allowing me to use the tests, build, render, deploy and verify skaffold stages in my entire pipeline and deploy the application to a k8s cluster in GCP in a full GitOps manner.

Thanks for reading and see you the next week for more! 😃

A Big KUDOS to the team #skaffold for a great job, if you want to know more about you can reach them at slack or in their repo

Support me

If you like what you just read and you find it valuable, then you can buy me a coffee by clicking the link in the image below.

]]>

Una mini API para hacer benchmark de Symfony con RoadRunner (Parte II)

Raul Castellanos — Fri, 30 Sep 2022 06:01:55 GMT

Esta es la continuacin de la primera entrega que puedes leer aqui -> https://blog.equationlabs.io/una-mini-api-para-hacer-benchmark-de-symfony-con-roadrunner-parte-i

TLDR; Hemos desarrollado una pequea API (PHP 8.1 + Symfony v6.1) utilizando RoadRunner como application server para realizar un pequeo benchmark de cuanta mejora tenemos al reemplazar Nginx por RoadRunner

Si se preguntan porque eleg RoadRunner en vez de otros SAPI que hacen lo mismo (SwoolePHP, ReachPHP, etc) es porque utilizando este ultimo, la manera de desarrollar se mantiene variando un poco como manejamos las conexiones persistentes y su fcil implementacin con Symfony y su componente Runtime.

Bien, lo que tenemos ahora es una API con un solo endpoint que siempre retorna el mismo resultado, y queremos ver (a manera de benchmark) cuantos request puede manejar y en cuanto tiempo comparado con la misma API pero utilizando NGINX como convencionalmente es utilizado.

Para hacer el benchmark lo mas sencillo posible, vamos a utilizar Vegeta - para conocer mas de Vegeta puedes mirar aqu -

El escenario es la misma aplicacin con PHP+FPM+NGINX y por otro lado PHP+RoadRunner en ambas utilizaremos el siguiente comando de vegeta para hacer la prueba de carga:

cat src/tests/benchmark/target.txt | vegeta attack -rate 100 -duration=60s"

Leyenda: Rate: 100 Requests por Unidad (por default es 1s, con lo cual serian 20 req/s)Duration: 60segundos

El reporte nos generara la data para poder determinar los percentiles de respuesta de nuestros requests a lo largo de la prueba y as poder medir la latencia en ambos escenarios.

PHP + FPM + NGINX

PHP + ROADRUNNER

Si compramos la data de los histogramas resultantes de las pruebas (Vegeta permite exportar resultados que luego pueden ser graficados y cruzados con otros histogramas) nos da la siguiente escena:

EL percentil 95% parece estar muy cerca en ambos caos, pero en el caso de RoadRunner se mantiene constante a lo largo de la prueba de carga con lo cual (para el escenario de la prueba) su degradacin en el tiempo es mnima (el tiempo de respuesta a los usuarios se mantiene estable)

Hasta ac mi ensayo de prueba de carga utilizando PHP + RoadRunner, espero les haya gustado y si es as pues dejame tu comentario o like en el post.

]]>

Una mini API para hacer benchmark de Symfony con RoadRunner (Parte I)

Raul Castellanos — Tue, 19 Jul 2022 07:03:14 GMT

PHP ha avanzado mucho desde sus inicio, y eso incluye un ecosistema que ahora incluye poderosos application servers cmo lo es RoadRunner. Este ltimo es un application server, load balancer y process manager hecho en GoLang, que utilizando GoRoutines y multithreading, mantiene la aplicacin PHP en memoria entre requests eliminando la necesidad de boot loading y code loading process reduciendo as, la latencia de tu aplicacin pudiendo servir mas requests en menos tiempo. (performance at it's best)

Algunas "features" interesantes de RoadRunner:

Production-ready PSR-7 compatible HTTP, HTTP2, FastCGI server
Agnstico el framework de trabajo
Servidor de mtricas integrado (prometheus)
Integraciones para Symfony, Laravel, Slim, CakePHP, Zend Expressive, Spiral
y mas...

Es importante recalcar que existen variedad de Runtimes que pueden ser utilizados con PHP (Swoole, ReactPHP, Bref y hasta el siempre conocido PHP-FPM) en nuestro caso vamos a utilizar RoadRunner por su simplicidad de instalacin y conociendo de antemano que Swoole es capaz de rendir mas performance hoy en da que RoadRunner

Para probar un poco como funciona, vamos a implementar una pequea API (utilizando un poco de CQRS) con un solo endpoint, que nos permita, recibir un request, ir a otra api externa (tipo clima), recibir la respuesta, transformarla y retornarla al cliente final.

Ac un pequeo diagrama de secuencia para entender el flujo de la misma

NOTA: Todo esto est disponible en el README del repositorio que esta al final de este post.

Utilizar RoadRunner con Symfony es bastante sencillo, recuerda que no necesitaras ni Nginx ni FPM para esto, solo el binario de RoadRunner, tu cdigo fuente y sus dependencias declaradas en el archivo de composer por lo tanto el setup es muy simple, en mi caso el Dockerfile es el siguiente:

FROM spiralscout/roadrunner:2.10.5 as rrFROM php:8.1 as phpRUN apt-get update && apt-get install -y libzip-dev unzip bash# Copy ComposerCOPY --from=composer:2 /usr/bin/composer /usr/bin/composer# Source CodeADD . .RUN composer install -o# Copy RoadRunnerCOPY --from=rr /usr/bin/rr /usr/bin/rr

RoadRunner necesita de su archivo de configuracin .rr.yaml para funcionar, este archivo en mi caso, incluye la clase del lado de symfony que servir de entrypoint (esta delcarado como una variable de ambiente llamada APP_RUNTIME).

Para poder hacer funcionar RoadRunner con Symfony es necesario hacer uso del componente symfony/runtime e instalar el runtime adecuado, que en nuestro caso ser https://github.com/php-runtime/roadrunner-symfony-nyholm .

El componente symfony/runtime desacopla la lgica de boostraping de cualquier estado global para asegurarse que la aplicacin pueda ejecutarse con variedad de runtimes como PHP-PM, ReactPHP, Swoole, RoadRunner, etc. sin ningn cambio en tu aplicacin. para conocer mas puedes ver la documentacin oficial aqui: https://symfony.com/doc/current/components/runtime.html

Nuestro archivo de configuracin de RoadRunner (para este caso practico) es el siguiente:

version: "2.7"server:  command: "php public/index.php"  env:    - APP_RUNTIME: Runtime\RoadRunnerSymfonyNyholm\Runtimehttp:  address: 0.0.0.0:8080  middleware: [ "gzip" ]  pool:    num_workers: ${RR_NUM_WORKERS}    max_jobs: ${RR_MAX_JOBS}    supervisor:      max_worker_memory: ${RR_MAX_WORKER_MEMORY}metrics:  address: 0.0.0.0:2112logs:  mode: production  channels:    http:      level: error     server:      level: error      mode: raw    metrics:      level: error

Puedes encontrar mas detalles sobre como configurar RoadRunner para cada ambiente (dev, debug, production, etc) en el siguiente enlace https://roadrunner.dev/docs/intro-config/2.x/en

Adicionalmente en tu docker-compose debes indicar en el command de inicializacin donde esta el binario de RoadRunner y que archivo de configuracin quieres utilizar, por ejemplo debera quedar algo como esto:

php:    build:      dockerfile: Dockerfile      context: .    ports:      - "8080:8080"      - "2112:2112" # para exponer las mtricas del servidor embebido de prometheus que traer RR    env_file:      - .env    working_dir: /opt    volumes:      - ./:/opt    command: [ '/usr/bin/rr', 'serve', '-c', '.rr.yaml' ]

Una de las cosas que me gusta de RoadRunner es que trae por default un servidor de Prometheus embebido, con lo cual automticamente expone mtricas para ser consumidas por un prometheus collector de manara muy sencilla en http://{host}:2112/metrics y ademas te permite a travs de una cmoda interfaz agregar tus mtricas custom de aplicacin utilizando el mismo servidor sin necesidad tener que instalar libreras adicionales en tu aplicacin o un servidor adicional de prometheus para exponer mtricas.

Como plus handy, en la documentacin oficial tienes un dashboard de grafana para poder monitorear toda tu aplicacin que se este ejecutando sobre RoadRunner (workers, consumo de CPU, etc)

Con esto ya tenemos la primera parte para poder comenzar nuestro pequeo benchmarking.

En la segunda entrega de este post, vamos a ir directo a las diferentes ejecuciones del benchmark comparando PHP-FPM contra RoadRunner utilizando una herramienta de HTTP Load llamada Vegueta. (puedes tambin utilizar Apache Bench o WRK tool)

Puedes conseguir mas informacin de Vegeta en este enlace https://github.com/tsenart/vegeta

Hasta el prximo post!

]]>

Trunk Based Development, Kubernetes y GCP: Un pipeline con la ayuda de Gitlab, Kaniko, Skaffold y Terraform

Raul Castellanos — Tue, 31 Aug 2021 00:17:12 GMT

Esta es la segunda entrega del articulo k8s desde dev hasta prod con Gitlab, Skaffold, Kustomize y Kaniko donde arme el skeleton base para esta segunda entrega, al igual que el anterior al final del artculo estar el enlace al repositorio con todo el cdigo

Premisa

Ya tenemos un pipeline que cumple con las siguientes pasos:

Test test suites ejecutadas por PHPUnit
Build con Kaniko construimos las imgenes, las tagueamos y las enviamos a nuestro registro de imgenes (utilizaremos el mismo de gitlab en este caso), Kaniko se encarga de guardar una capa de cache en el mismo registro.
Deploy con Skaffold se construyen dinmicamente los manifiestos junto con las imgenes construidas en el paso anterior generando un manifiesto final que es aplicado en el cluster
Destroy con Skaffold se puede tambin eliminar del manifiesto aplicado actualmente.

Lo que queremos ahora es, eliminar un stage Destroy, y agregar un par de pasos ms para aprovisionamiento de infraestructura con Terraform, el ciclo quedara ms o menos as:

Vamos a ello

Como esta es la continuacin de la primera parte , no los voy a aburrir en la creacin del pipeline, sino que nos enfocaremos en la mejora del del mismo y de los archivos de instrucciones de Terraform.

Estructura de Archivos

Vamos a crear una nueva carpeta infrastructure y una sub carpeta terraform a nivel del root dir, donde irn colocados todos los archivos de terraform

Luego de esto vamos a crear los archivos declarativos para aprovisionar un cluster en nuestra infraestructura (en mi caso estoy utilizando Google Cloud). La idea principal es que adicionalmente a los clusters permanentes (staging y produccin) estos archivos de terraform se encarguen de crear cluster temporales que permitan que los equipos cuenten dinmicamente con un cluster para probar sus features y que este mismo cluster temporal pueda eliminarse una vez se haga el merge de esa branch a la rama main del repositorio.

Para esto vamos a crear los archivos de terraform y aparte vamos a colocar un webhook en GitLab al momento del merge request para eliminar dicho cluster temporal y el environment temporal de gitlab.

Archivos de Skaffold y Kustomize para ambientes `review`

En un nterin, como estamos utilizando skaffold para los ciclos de CI/CD, vamos a crear rpidamente un nuevo profile llamado review para nuestras aplicaciones de ambientes temporales/dinmicos para el manejo de los manifiestos de kubernetes para esto podemos hacer una copiar del folder staging que esta dentro de deployments/k8s/environments teniendo en cuenta cambiar los keys de staging a review

Vamos con Terraform

En lugar de hacer el tpico archivo main.tf en este caso y para mejor visualizacin vamos a separarlos por su funcin.

Empecemos con el 0-provider.tf donde, como su nombre lo indica, vamos a generar las instrucciones para que terraform sepa con que proveedor de servicios en la nube estamos trabajando (en nuestro caso Google Cloud), previamente necesitars haber creado previamente tus credenciales de service account para que puedas comunicarte con tu proveedor (GCP -> IAM & Admin > Service Accounts, y luego hacer click en Create Service Account.)

Los valores var.* sern definidos mas adelante en un archivo de terraform conocido como tfvars esto nos permitir en ese archivo escribir las variables dinmicas antes de inicializar el plan y aplicarlo.

# Google Cloud Platform Provider# https://registry.terraform.io/providers/hashicorp/google/latest/docsprovider "google" {  credentials = file("../configs/service-account.json")  project     = var.project_id  region      = var.region}terraform {  required_providers {    google = {      source = "hashicorp/google"      version = "3.5.0"    }  }}

En tu consola para ir probando localmente puedes ejecutar el siguiente comando para inicializar terraform, esto descargara las primeras dependencias y las instalar en un folder .terraform del mismo directorio de trabajo y crear un archivo .lock.hcl que, como buena practica, deberas guardarlo en tu repo.

$: terraform init

Adicionalmente a esto vamos a crear un archivo 1-cluster.tf para definir las instrucciones de terraform para crear un cluster en nuestra infraestructura de Google Cloud Platform junto con la instruccin para crear una VPC para este cluster.

resource "google_compute_network" "vpc_network" {  name = var.cluster_network}resource "google_container_cluster" "gke-cluster" {  name               = var.cluster_name  network            = var.cluster_network  location           = var.region  initial_node_count = 1}

Luego estarn los dos ltimos archivos, vars.tf y terraform.tfvars dnde estarn las variables globales y sus valores y placeholders para que sean accesibles para terraform.

variable "project_id" {  type  = string}variable "region" {  type  = string}variable "cluster_name" {  type  = string}variable "network_name" {  type  = string}

project_id = "YOUR_GCP_PROJECT_ID"region     = "us-central-1c"cluster_name = "PLACEHOLDER_CLUSTER"network_name = "PLACEHOLDER_NETWORK"

Luego de esto nos queda completar nuestro pipeline de GitLab con los jobs que debemos sumar para terraform (incluye 3 validate, init, plan y apply) y para el deploy del ambiente dinmico tomando en cuenta que solo debe crear dichos jobs si el branch es un feature branch y que no sea la rama main.

Si ves en detalle, hemos creado una variable de CI/CD de GitLab que contiene las credenciales de la service-account ( SERVICE_ACCOUNT_GCP) de Google Cloud para que pueda estar accesible para el pipeline y pasarla a los jobs de terraform en forma de archivo json.

.terraform:  image:    name: hashicorp/terraform:1.0.5    entrypoint:      - '/usr/bin/env'      - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'  before_script:    - cd infrastructure && mkdir -p configs && cd configs    - echo $SERVICE_ACCOUNT_GCP | base64 -d > service-account.json    - cd ../terraform    - sed -i "s/\PLACEHOLDER_CLUSTER/$CI_COMMIT_REF_SLUG" terraform.tfvars    - sed -i "s/\PLACEHOLDER_NETWORK/$CI_COMMIT_REF_SLUG" terraform.tfvars    - terraform init  cache:    key: terraform-cache    paths:      - .terraform  rules:    - if: '$CI_COMMIT_BRANCH =~ /feature/'    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'validate:  extends: .terraform  stage: provision  script:    - terraform validateplan:  extends: .terraform  stage: provision  script:    - terraform plan -out plan.tfplan  needs:    - validate  artifacts:    paths:      - plan.tfplanapply:  extends: .terraform  stage: provision  script:    - terraform apply -input=false plan.tfplan  needs:    - plan  rules:    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'      when: manualapply:  extends: .terraform  stage: provision  script:    - cp $CI_PROJECT_DIR/planfile ./    - terraform apply -input=false "planfile"  needs:    - plan  rules:    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'      when: manualdeploy:feature:  extends: .skaffold  stage: deploy  environment:    name: "$CI_COMMIT_REF_NAME"    url: $CI_COMMIT_SHORT_SHA.features.equatonlabs.io  needs:    - build:api  script:    - skaffold deploy -f deployment/skaffold.yaml -p feature -a latest-build.json --status-check=true  rules:    - if: '$CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'      when: manualdestroy:feature:  extends: .terraform  stage: destroy  environment:    name: $CI_COMMIT_REF_NAME    url: $CI_COMMIT_SHORT_SHA.features.equatonlabs.io    action: stop  script:    - terraform destroy  rules:    - if: $CI_MERGE_REQUEST_APPROVED    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

Ahora juntemos todo

Una vez tengamos todos nuestros archivos en lugar es momento de hacer nuestro commit & push al repositorio y seguir la ejecucin del pipeline de GitLab y sus salidas para asegurarnos que esta todo en orden.

Tendramos este escenario:

Tener 2 nuevos stages provision y deploy cuando la rama comienza con feature/
Dinmicamente nuestro cluster y la vpc tendrn el nombre de la variable runtime CI_COMMIT_REF_SLUG (ver mas ac )
En GitLab se creara un environment dinmico basado en la variable CI_COMMIT_REF_NAME
Una vez aprobado el MR a la rama main, se dispara un job que elimina el cluster temporal que se utilizo para desarrollar y probar la feature y as no incurrir en costos innecesarios.
Una vez aprobado el MR a la rama main se eliminar tambin el environment creado en GitLab
En la rama main no debe aparecer el stage de provision ya que esos cluster no son permanentes en el tiempo y se manejan fuera de este pipeline.

Pipeline en Features

Environment dinmico y deploy dashboard

Google Cloud con el Cluster Creado

Ahora nos queda probar, para completar el circuito, que al aprobar el MR, se ejecute el paso de destroy:feature que elimine el cluster y el environment de el deploy dashboard de GitLab

Pipeline con el MR aprobado

Y esto es todo por ahora amigos, como siempre compartan, que compartir hace bien. Les dejo ms abajo el repo con todos los files que vimos hoy para que los puedan ojear mas a detalles.

https://gitlab.com/equationlabs/stacks/emr/endovelicus

]]>

k8s desde dev hasta prod con Gitlab, Skaffold, Kustomize y Kaniko

Raul Castellanos — Wed, 25 Aug 2021 22:15:36 GMT

La prueba de concepto

Vamos a trabajar con lo siguiente:

Repositorio en GitLab con una aplicacin de Symfony default
Cluster activo de Kubernetes puedes tenerlo en AWS o GCP y localmente con utilizar en Mac Docker-Desktop o minikube.
kubectl CLI oficial de kubernetes para interactuar con tu cluster
Skaffold para manejar el ciclo de push, deploy de tu pipeline
Kaniko para manejar el ciclo de build de tus imgenes

Instalando todos los requisitos

Basado en MacOS sin embargo en los sitios de cada herramienta esta bien detallado cmo instalar para los dems sistemas operativos.

kubectl: En tu terminal ejecuta brew install kubectl y luego para verirficar que esta correctamente instalado ejecuta kubectil version --client=true
Skaffold: de igual manera en tu terminal ejecuta brew install skaffold

Ahora: Manos a la obra!

Manejaremos la siguiente estructura de archivos para este tutorial

project_root:api: # Archivos de Symfony y Dockerfiledeployment: # Archivos de CI/CD    base:        configs:            nginx:                default.conf        _registry-secret.yaml        api-app.yaml        api-load-balancer-service.yaml        kustomization.yaml    environments:        dev:            api-app.patch.yaml            kustomization.yaml   skaffold.yaml   .build-template.json.gitlab-ci.yaml

Skaffold, es una herramienta de lineas de comandos desarrollada por Google, que hace el desarrollo local con k8s un soplo, teniendo en cuenta lo complicado que es manejar todos los manifiestos yaml de k8s, buildear, pushear, etc, esta herramienta funciona a modo de hot reloading para desarrollo local, con lo cual ante cualquier cambio de tu cdigo, buildea, rearma los yamls y deploya para que puedas seguir desarrollando sin necesidad de trabajos manuales sobre los yamls.

Kustomize es una herramienta de comandos que ahora viene incluida por default con k8s y que permite poder "templatizar" tus manifiestos de k8s y permitirte as poder a partir de un manifiesto base "patchear" manifiestos k8s para cada uno de tus ambientes.

Veamos a ahora como es nuestro archivo de configuracin de Skaffold:

apiVersion: skaffold/v2beta21kind: Configmetadata:  name: api-appbuild:  artifacts:    - image: api      context: api      docker:        dockerfile: Dockerfile      sync:        infer:          - '**/*.php'          - '**/*.js'profiles:  - name: development    build:      local:        push: false    deploy:      kubeContext: docker-desktop # or your local k8s cluster context like minikube      kustomize:        paths:          - deployment/k8s/environments/dev

En este paso, ya lo que nos queda es armar nuestros manifiestos basados en los servicios y contenedores que nuestro aplicativo necesite, y junto con kustomize ir modificando las variaciones para cada stage, en el repositorio podrn ver un poco mas en detalle como estn construidos estos manifiestos.

Luego de esto podramos hacer el primer intento de correr localmente skaffold y hacer cambios en nuestro cdigo y con esto ya tendremos nuestro ciclo de desarrollo local completo.

{} ~ skaffold dev -p development -f deployment/skaffold.yaml

Ahora: Pipelines en GitLab y cluster en Google Cloud

El paso ms importante en esta etapa es construir nuestro archivo .gitlab-ci.yml que es el encargado de orquestar todos los pasos a ejecutarse en nuestro pipeline, en este caso sern 4 pasos (jobs) para este tutorial:

Test test suites ejecutadas por PHPUnit
Build con Kaniko construimos las imgenes, las tagueamos y las enviamos a nuestro registro de imgenes (utilizaremos el mismo de gitlab en este caso), Kaniko se encarga de guardar una capa de cache en el mismo registro.
Deploy con Skaffold se construyen dinmicamente los manifiestos junto con las imgenes construidas en el paso anterior generando un manifiesto final que es aplicado en el cluster
Destroy con Skaffold se puede tambin eliminar del manifiesto aplicado actualmente.

Lo bueno de construir tus imgenes con Kaniko (al menos para mi) es que guarda en el mismo registro de imgenes una capa de cache, para que las posteriores construcciones sean mucho ms rpidas.

Luego de esto si debemos asegurarnos que nuestro cluster de K8s esta integrado al proyecto en GitLab, en realidad es un paso bastante sencillo y se puede ver detallado aqu

Una vez integrado tu cluster en tu proyecto de GitLab, el paso deploy con skaffold del pipeline ser capaz de promover el manifiesto k8s directo en tu cluster de Google Cloud o de Amazon Web Services.

Enlaces a recursos

Kaniko -> https://github.com/GoogleContainerTools/kaniko
Skaffold -> https://skaffold.dev/
K8s CLI aka kubectl -> https://kubernetes.io/docs/tasks/tools/

https://gitlab.com/rcastellanosm/gitops-example-with-kaniko-and-skaffold

]]>

Desde mi Hamaca

From PHP to Rust: Migrating a REST API between these two languages. (Part I)

What's RUST Language

The Application

The Migration

File Structures

Rust main entrypoint

Compile and Run

Support Me

Managing database migrations safely in high replicated k8s deployment.

The Problem

When to run migrations (the workflow)

Job, InitContainer and RollingUpdates

Safety recommendations

Support Me

How to build a CI/CD workflow with Skaffold for your application (Part III)

Let's recap: The Workflow

Gitlab K8s agent and Security

Deployment and Safety Recommendations for K8s Agents

Provisioning cluster with terraform

Next

Support me

How to build a CI/CD workflow with Skaffold for your application (Part II)

Lets recap the Workflow

The Makefile

The skaffold file

The .gitlab-ci.yml Pipeline

Feature Branches Workflow (trigger by merge_request commit):

Main Branch Workflow (trigger by a TAG):

BONUS: Kaniko image Builder

Deployment safety considerations

Next Chapter

Support me

How to build a CI/CD workflow with Skaffold for your application (Part I)

The Toolset

The Workflow

The Application

Folder Structure and Orchestration process

Next Chapter

Support me

Una mini API para hacer benchmark de Symfony con RoadRunner (Parte II)

PHP + FPM + NGINX

PHP + ROADRUNNER

Una mini API para hacer benchmark de Symfony con RoadRunner (Parte I)

Trunk Based Development, Kubernetes y GCP: Un pipeline con la ayuda de Gitlab, Kaniko, Skaffold y Terraform

Premisa

Vamos a ello

Estructura de Archivos

Archivos de Skaffold y Kustomize para ambientes review

Vamos con Terraform

Ahora juntemos todo

k8s desde dev hasta prod con Gitlab, Skaffold, Kustomize y Kaniko

Instalando todos los requisitos

Ahora: Manos a la obra!

Ahora: Pipelines en GitLab y cluster en Google Cloud

Rust `main` entrypoint

When to run migrations `(the workflow)`

`Job`, `InitContainer` and `RollingUpdates`

Let's recap: `The Workflow`

Gitlab `K8s agent` and Security

Deployment and Safety Recommendations for `K8s Agents`

Provisioning cluster with `terraform`

Lets recap the `Workflow`

The `skaffold` file

The `.gitlab-ci.yml` Pipeline

BONUS: `Kaniko` image Builder

Archivos de Skaffold y Kustomize para ambientes `review`