Over time, as the project grows, sooner or later the question of upgrading versions of packages, modules, and charts will arise. You can do it manually, of course, but only up to a certain point, because eventually you simply won’t be able to physically monitor and update everything. There are many solutions for automating such… Read More »
Sometimes, when deploying Helm charts, the error “UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress” may appear: It can occur because the previous deployment failed due to errors in the chart, or the connection between the build machine and the Kubernetes cluster was lost. Check the release status with ls –all: $ helm -n dev-backend-api-ns… Read More »
We have a relatively large spending on AWS NAT Gateway Processed Bytes, and it became interesting to know what exactly is processed through it. It would seem that everything is simple – just turn on VPC Flow Logs and see what’s what. But when it comes to AWS Elastic Kubernetes Service and NAT Gateways, things… Read More »
In the post GitHub Actions: Deploying Dev/Prod Environments with Terraform I’ve already touched on the topic of GitHub Actions Reusable Workflows and Composite Actions a bit, so it’s time to learn more about it. What needs to be done: currently in my project, we write Workflow files in each repository separately. However, since all processes… Read More »
After the latest Arch Linux upgrade, Yay reported the following error: yay: error while loading shared libraries: libalpm.so.13: cannot open shared object file: No such file or directory First, let’s check if we have the libalpm library file, and which version: $ sudo find / -type f -name “*.so*” | grep libalpm /usr/lib/libalpm.so.14.0.0 So, we… Read More »
In the GitHub Actions: deploying Dev/Prod environments with Terraform blog I’ve already described how we can implement CI/CD for Terraform with GitHub Actions, but there is one significant drawback to that solution: there is no way to review changes before applying them with terraform apply. GitHub Actions has the ability to use Reviewing deployments to… Read More »
Tracing allows you to track requests between components, that is, for example, when using AWS and Kubernetes we can trace the entire path of a request from AWS Load Balancer to Kubernetes Pod and to DynamoDB or RDS. This helps us both to track performance issues – where and which requests are taking a long… Read More »
Each WorkerNode in a Kubernetes cluster can have a limited number of Pods running, and this limit is determined by three parameters: CPU: the total number of requests.cpu cannot be more than the number of CPUs on the Node Memory: the total number of requests.memory cannot be more than the Memory on the Node IP:… Read More »
An example of creating a Terraform module to automate log collection from AWS Load Balancers in Grafana Loki. See how the scheme works in the Grafana Loki: collecting AWS LoadBalancer logs from S3 with Promtail Lambda blog. In short, ALB writes logs to an S3 bucket, from where they are picked up by a Lambda… Read More »
I didn’t plan this post at all as I thought I would do it quickly, but it didn’t work out quickly, and I need to dig a little deeper into this topic. So, what we are talking about: we have AWS Load Balancers, logs from which are collected to Grafana Loki, see. Grafana Loki: collecting… Read More »