Forem: Umair-khurshid

Using Packer and Proxmox to Build Templates

Umair-khurshid — Fri, 23 Aug 2024 17:57:11 +0000

Automating the deployment of virtual machines (VMs) is an essential part of modern IT infrastructure. Packer and Proxmox are two powerful tools that, when combined, offer an effective solution for automated VM image creation. This article explores why using Packer with Proxmox is beneficial, as well as the practical implementation of this combination.

Why use Packer for Proxmox?

Reproducibility and consistency: Packer lets you define all the configurations of a VM image in a file in HCL or JSON format. By using Packer, you guarantee reproducibility in the image creation process, ensuring consistency in your deployments.
Cross-platform support: Packer supports multiple vendors, and Proxmox is just one of them. This flexibility allows you to create images that can be deployed on different types of platform, whether on-premise or in the cloud.
Optimisation of resources: You can automate the creation of lightweight, optimised images, eliminating unnecessary components and applying configurations specific to your environment.
Time savings: Automating the image creation process significantly reduces the time needed to prepare VMs. You can automate tasks such as software installation, network configuration and many others, speeding up the deployment cycle.

How to use Packer on Proxmox?

Install Packer on your development machine and configure it to use the Proxmox provider by specifying the connection details (IP address of the server where the image will be created, username, password). For installation, I can only suggest that you visit the official website.

There are then 3 steps in the Packer image creation process:

Creation of Packer model definition and automated OS configuration files
Create a Packer configuration file in HCL or JSON format describing the steps required to create your Proxmox image.
Specify parameters such as operating system type, provisioning scripts and Proxmox-specific parameters.

Operating systems can be configured autonomously and dynamically, without having to click or enter commands. To do this, the use of configuration files must be taken into account and maintained in line with changing requirements.

Build execution:
Start the building process with Packer. Packer will connect to your Proxmox host, create a temporary VM, apply configurations and will transform it to a template. This template will be the source for your deployment, the template to clone.

Validation:

Check the generated image by deploying it on a Proxmox VM.
Distribute the image to other Proxmox hosts or save it for future use.

My use case and my configuration

I use Packer in my homelab to generate templates (Debian 12 and Ubuntu 22.04) which I then re-use via Open Tofu to build the VMs I need. To make customization easier, I use variables as much as possible. So the base file is static and only the variables (in a separate file) need to be modified as required.

I have already uploaded the Debian 12 ISO image to storage on my Proxmox host. It is possible to use Packer to download the ISO image from the Internet and send it to your Proxmox host. I didn't choose this solution because I wanted to limit web access and set myself up for full "self-hosting".

To make the connection between Proxmox and Packer, I created a user in the "pve" realm, then I created a token for this user and finally assigned rights to the token API:

In the "Datacenter" tab, go to the "Permissions" section and click on "Users" and the "Add" button. Enter the necessary information (no password required) then save the form. Remember the name of this user.
Still in the "Permissions" section, click on "API Token" and the "Add" button. Select the user previously created, give the token a name (to remember) and continue with the form; a secret will then be displayed and must be stored in a safe place. This secret is required to operate Proxmox with Packer.
Finally, go back to the "Permissions" section, then click on the "Add - API Token Permission" button: select the user with the API ID you just created, and add the following rights to it:
Path: "/"
Role : "PVEAdmin" (it's a lot, but there's no choice. Alternatively, you can create your own role with the necessary rights…)
Propagate: tick the box (useful for having permissions over the entire infrastructure - machines, storage, network)

In the folder where my files are stored, I have created an "autoinstall" subfolder, to put the preseed file that allows Debian to be installed automatically.

~/git/homelab/packer$ tree
.
├── autoinstall
│   ├── preseed.cfg
├── customdeb12.pkrvars.hcl
└── debian12.pkr.hcl

From now on, here are the files needed to create a Debian 12 image with Packer, for Proxmox:
debian12.pkr.hcl" file: this is the file that defines the Packer requirements for our use case, the basis of our model, the connection to the Proxmox server and the variables.

// debian12.pkr.hcl
packer {
  required_plugins {
    name = {
      version = "1.1.6"
      source  = "github.com/hashicorp/proxmox"
    }
  }
}
variable "bios_type" {
  type = string
}
variable "boot_command" {
  type = string
}
variable "boot_wait" {
  type = string
}
variable "bridge_firewall" {
  type    = bool
  default = false
}
variable "bridge_name" {
  type = string
}
variable "cloud_init" {
  type = bool
}
variable "iso_file" {
  type = string
}
variable "iso_storage_pool" {
  type    = string
  default = "local"
}
variable "machine_default_type" {
  type    = string
  default = "pc"
}
variable "network_model" {
  type    = string
  default = "virtio"
}
variable "os_type" {
  type    = string
  default = "l26"
}
variable "proxmox_api_token_id" {
  type = string
}
variable "proxmox_api_token_secret" {
  type      = string
  sensitive = true
}
variable "proxmox_api_url" {
  type = string
}
variable "proxmox_node" {
  type = string
}
variable "qemu_agent_activation" {
  type    = bool
  default = true
}
variable "scsi_controller_type" {
  type = string
}
variable "ssh_timeout" {
  type = string
}
variable "tags" {
  type = string
}
variable "io_thread" {
  type = bool
}
variable "cpu_type" {
  type    = string
  default = "kvm64"
}
variable "vm_info" {
  type = string
}
variable "disk_discard" {
  type    = bool
  default = true
}
variable "disk_format" {
  type    = string
  default = "qcow2"
}
variable "disk_size" {
  type    = string
  default = "16G"
}
variable "disk_type" {
  type    = string
  default = "scsi"
}
variable "nb_core" {
  type    = number
  default = 1
}
variable "nb_cpu" {
  type    = number
  default = 1
}
variable "nb_ram" {
  type    = number
  default = 1024
}
variable "ssh_username" {
  type = string
}
variable "ssh_password" {
  type = string
}
variable "ssh_handshake_attempts" {
  type = number
}
variable "storage_pool" {
  type    = string
  default = "local-lvm"
}
variable "vm_id" {
  type    = number
  default = 99999
}
variable "vm_name" {
  type = string
}
locals {
  packer_timestamp = formatdate("YYYYMMDD-hhmm", timestamp())
}
source "proxmox-iso" "debian12" {
  bios                     = "${var.bios_type}"
  boot_command             = ["${var.boot_command}"]
  boot_wait                = "${var.boot_wait}"
  cloud_init               = "${var.cloud_init}"
  cloud_init_storage_pool  = "${var.storage_pool}"
  communicator             = "ssh"
  cores                    = "${var.nb_core}"
  cpu_type                 = "${var.cpu_type}"
  http_directory           = "autoinstall"
  insecure_skip_tls_verify = true
  iso_file                 = "${var.iso_file}"
  machine                  = "${var.machine_default_type}"
  memory                   = "${var.nb_ram}"
  node                     = "${var.proxmox_node}"
  os                       = "${var.os_type}"
  proxmox_url              = "${var.proxmox_api_url}"
  qemu_agent               = "${var.qemu_agent_activation}"
  scsi_controller          = "${var.scsi_controller_type}"
  sockets                  = "${var.nb_cpu}"
  ssh_handshake_attempts   = "${var.ssh_handshake_attempts}"
  ssh_pty                  = true
  ssh_timeout              = "${var.ssh_timeout}"
  ssh_username             = "${var.ssh_username}"
  ssh_password             = "${var.ssh_password}"
  tags                     = "${var.tags}"
  template_description     = "${var.vm_info} - ${local.packer_timestamp}"
  token                    = "${var.proxmox_api_token_secret}"
  unmount_iso              = true
  username                 = "${var.proxmox_api_token_id}"
  vm_id                    = "${var.vm_id}"
  vm_name                  = "${var.vm_name}"
  disks {
    discard      = "${var.disk_discard}"
    disk_size    = "${var.disk_size}"
    format       = "${var.disk_format}"
    io_thread    = "${var.io_thread}"
    storage_pool = "${var.storage_pool}"
    type         = "${var.disk_type}"
  }
  network_adapters {
    bridge   = "${var.bridge_name}"
    firewall = "${var.bridge_firewall}"
    model    = "${var.network_model}"
  }
}
build {
  sources = ["source.proxmox-iso.debian12"]
}

Custom.pkvars.hcl" file: Variables are used to customise the model.

// custom.pkvars.hcl
bios_type                = "seabios"
boot_command             = "<esc><wait>auto console-keymaps-at/keymap=fr console-setup/ask_detect=false debconf/frontend=noninteractive fb=false url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg<enter>"
boot_wait                = "10s"
bridge_name              = "vmbr0"
bridge_firewall          = false
cloud_init               = true
cpu_type                 = "x86-64-v2-AES"
disk_discard             = true
disk_format              = "qcow2"
disk_size                = "12G"
disk_type                = "scsi"
iso_file                 = "local:iso/debian-12.4.0-amd64-netinst.iso"
machine_default_type     = "q35"
nb_core                  = 1
nb_cpu                   = 1
nb_ram                   = 2048
network_model            = "virtio"
io_thread                = false
os_type                  = "l26"
proxmox_api_token_id     = "packbot@pve!nom_token"
proxmox_api_token_secret = "aaaaaa-aaaa-bbbb-cccc-123456789012"
proxmox_api_url          = "https://ip_proxmox:8006/api2/json"
proxmox_node             = "nom_hôte_proxmox"
qemu_agent_activation    = true
scsi_controller_type     = "virtio-scsi-pci"
ssh_handshake_attempts   = 6
ssh_timeout              = "35m"
ssh_username             = "umair"
ssh_password             = "umairpwd"
storage_pool             = "stoCeph"
tags                     = "template"
vm_id                    = 99998
vm_info                  = "Debian 12 Packer Template"
vm_name                  = "pckr-deb12"

A few notes about these variables:

Don't forget to change the values of "bridge_name", "iso_file" (the name of the storage where the ISO image is and its name), "proxmox_", "ssh_*"…
The "boot_command" variable is used to force the ISO to use the preseed file
"cloud_init is installed and activated to make it easier for Open Tofu to configure VMs

I'll leave you to take the other variables into account and modify them to suit your needs.

"autoinstall/preseed.cfg" file: Debian installation configuration file, for zero-touch installation.

#_preseed_V1
d-i debian-installer/language string en
d-i debian-installer/country string EN
d-i debian-installer/locale string en_US.UTF-8
d-i localechooser/supported-locales multiselect en_US.UTF-8, en_US.UTF-8
d-i keyboard-configuration/xkb-keymap select en
d-i console-keymaps-at/keymap select en-latin9
d-i debian-installer/keymap string en-latin9
d-i netcfg/choose_interface select auto
d-i netcfg/link_wait_timeout string 5
d-i netcfg/dhcp_timeout string 60
d-i netcfg/get_hostname string pckr-deb12
d-i netcfg/get_domain string local.xyz.com
d-i netcfg/wireless_wep string
d-i hw-detect/load_firmware boolean false
d-i mirror/country string FR
d-i mirror/http/hostname string deb.debian.org
d-i mirror/http/directory string /debian
d-i mirror/http/proxy string
d-i passwd/root-login boolean true
d-i passwd/make-user boolean true
d-i passwd/root-password password umairpwd
d-i passwd/root-password-again password umairpwd
d-i passwd/user-fullname string umair
d-i passwd/username string umair
d-i passwd/user-password password umairpwd
d-i passwd/user-password-again password umairpwd
d-i clock-setup/utc boolean true
d-i time/zone string US/New York
d-i clock-setup/ntp boolean true
d-i clock-setup/ntp-server string  0.us.pool.ntp.org
d-i partman-auto/disk string /dev/sda
d-i partman-auto/method string lvm
d-i partman-auto-lvm/guided_size string max
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select multi
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i partman-md/confirm boolean true
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i partman/mount_style select uuid
d-i base-installer/install-recommends boolean false
d-i apt-setup/cdrom/set-first boolean false
d-i apt-setup/use_mirror boolean true
d-i apt-setup/security_host string security.debian.org
tasksel tasksel/first multiselect standard, ssh-server
d-i pkgsel/include string qemu-guest-agent sudo ca-certificates cloud-init
d-i pkgsel/upgrade select safe-upgrade
popularity-contest popularity-contest/participate boolean false
d-i grub-installer/only_debian boolean true
d-i grub-installer/with_other_os boolean false
d-i grub-installer/bootdev string default
d-i finish-install/reboot_in_progress note
d-i cdrom-detect/eject boolean true

With all the above files and the user configuration in Proxmox, you should be able to create a machine. The Packer commands to run are as follows:

# initialize the repository to retrieve:
packer init debian12.pkr.hcl
# validate Packer files:
packer validate -var-file=customdeb12.pkrvars.hcl debian12.pkr.hcl
# build the image, replacing the artefact if it already exists:
packer build -on-error=ask -force -var-file=customdeb12.pkrvars.hcl debian12.pkr.hcl

Easily Encode/Decode Kubernetes Secrets in Base64

Umair-khurshid — Sat, 27 Jul 2024 20:15:05 +0000

Something we have to do aLL the time when manipulating Secrets objects in Kubernetes is to display in plain text the “secrets” contained in our Secret (or to encode them).

For those who don't know, Secrets in Kubernetes are unfortunately not very secret, since they are nothing more or less than base64 encoded strings (which is therefore anthing but secure). To tell the truth, I even wonder why bother encoding them at all. The only security we add compared to ConfigMaps is simply that the string is not readable by a human who would stick his head over your shoulder.

Anyways, you are probably going to have to encode or decode strings in base64 and it's sometimes a bit of a pain. The commonly accepted method is to simply use the linux echo and base64 binaries.

echo "ma string" | base64
bWEgc3RyaW5nCg==

echo bWEgc3RyaW5nCg== | base64 -d
my string

It's a pain to type, but it's relatively trivial.

It's a trap!

Except there are traps!

The first one you will get when encoding. In my first example, the string is very short. And sometimes, size matters.

echo "my long string" | base64
bWEgc3RyaW5nIHRyw6hzIGxvbmd1ZSBzdHJpbmcgcG91ciBtb250cmVyIHF1ZSDDp2EgdmEgcGFz
IGxlIGZhaXJlCg==

Here we end up with a line break in our output string. But, if you copy and paste this into your Kubernetes YAML, you're going to get a big syntax error.

The YAML will only be valid if you put the entire string, on a single line.

echo "my long string" | base64 -w0
bWEgc3RyaW5nIHRyw6hzIGxvbmd1ZSBzdHJpbmcgcG91ciBtb250cmVyIHF1ZSDDp2EgdmEgcGFzIGxlIGZhaXJlCg==

And it's not over!

The 2nd trap is again a line break issue, but in the base64 string this time.

In fact, it's super treacherous because you won't see it on the screen at first, but you should know that echo adds a line break at the end of your string. The return you got in base64 therefore contains a line break, which will almost systematically be unwanted when managing Secrets.

So the correct command is not echo but echo -n !

echo "my string" | base64
bWEgc3RyaW5nCg==

echo -n "my string" | base64 -w0
bWEgc3RyaW5n

Okay this is starting to get really annoying...

To decode fortunately, it is simpler. The command given at the beginning is enough, even if it will be safer to add the “-n” to the echo:

echo -n bWEgc3RyaW5n | base64 -d
my string

Gain some characters

Since I'm lazy, I looked for a trick to save a few characters to type. There is a solution, but unfortunately it only works for decode, since in the case of encoding we risk adding an unwanted line break:

echo bWEgc3RyaW5n | base64 -d
base64 -d <<< bWEgc3RyaW5n
my string

We just saved 3 characters but especially a “|”, much more difficult to do on a standard qwerty keyboard than 3 “<”.

A little simpler

Here's a ittle script to make our lives easier:

~$ cat > b64 <<EOF 
> #!/bin/bash
> echo -e "Base64 encoding.. \n"
> for arg in "\$@"; do
>   echo "\$arg :"
>   echo -n "\$arg" | base64
>   echo
> done
> EOF
~$ cat > b64d <<EOF 
> #!/bin/bash
> echo -e "Base64 decoding.. \n"
> for arg in "\$@"; do
>   echo "\$arg :"
>   echo -n "\$arg" | base64 -d
>   echo
> done
> EOF
~$ sudo cp b64* /usr/local/bin/

You can now directly invoke b64 followed by any number of strings to have their value encoded, or b64d followed by any number of strings to decode them.

I am an Avid Vim User, Finally Migrated to Neovim! How does it work, what do I gain from it?

Umair-khurshid — Sun, 23 Jun 2024 19:00:05 +0000

Having migrated to Neovim, I will give you some feedback and give you the keys to understanding and succeeding in your migration to Neovim! First of all, a little context and history.

Vim, the essential

Who doesn't know Vim, if only through jokes about how to quit it? And for good reason Vim - or often its predecessor Vi, which has been around for over 44 years - often remains our most faithful ally, especially in minimal environments.

Developed in 1976 by Bill Joy, Vi was a real revolution, notably by introducing the use of the entire screen, which for the time was a real revolution. It must be said that at that time the majority of text editing was done using ed, from which Vi and Vim will inherit the modal aspect.

A decade later, a certain Vi user Bram Moolenaar sought to port it to the Amiga. He ended up developing version 1.0 of Vim in C in 1988. This version was intended to be an improved version of Vi, hence the acronym (VI iMproved).

Vim continues to evolve from year to year still in the hands of Bram Moolenaar, even if the pace of this evolution has decreased over the last 2 decades. This slowdown can be accentuated by the very closed contribution management policy. The proposals are complex to have the creator accept.

NeoVim, reinventing yourself without forgetting yourself

We might as well admit it, Vim development issues ended up impacting the user community. So much so that in 2014 part of the Vim community embarked on the NeoVim project, notably launching a fundraiser which was a success. The goal of NeoVim is simple: to create a more modern, extensible Vim, with better integrations, and of course a more efficient development community.

From December 2015, version 0.1 of NeoVim was released, offering support for a very large part of Vim's functionalities. The community will quickly expand and the number of users will increase. The versions will also follow one another, regularly offering new features. To give you an idea, today we are at version 0.10.

In short, a project which has already proven itself and which continues to evolve by gaining more and more features.

Why am I using Vim / NeoVim in 2024?

Except for specific development needs, I assume that the majority of you use VSCode, although I have no doubt that the more hipsters use an IDE from the IntelliJ suite. First of all, yes, Vim/Neovim are not IDEs, but code editors. That's not to say they can't fulfill the same needs as an IDE once custom configuration and plugins are added. In short, yes, in my opinion and for my use, it is comparable in this case.

I haven't always used Vim, I started on Eclipse in my early years when I was into Java EE development. Like many people, I suppose, I had the impression of using heavy software, full of overpowering features. But ultimately having the use of too little. Especially since at that time, I was still a student, I might as well tell you that when you move from Java to system-oriented C, your IDE is no longer suitable.

After that, I went to the dark side. Needless to say, I spent more time in front of a terminal than anything else, even if automation made it possible to limit manual tasks. Unfortunately, sometimes we have no choice and have to make changes often via SSH. Suffice it to say that your IDE will be of little help to you. So I did like everyone else, use Vim. At the beginning, it's complicated: modal functioning seems from another time and it feels like we are doing violence to ourselves. Over time, I found myself working largely over an SSH connection and had to start getting into Vim and Tmux, which remains, in my opinion, an excellent combo.

After this, I went back to working on my job. I could have started with an IDE, but in the end, I was starting to adapt to Vim. I wasn't an expert, but it was enough for my job. Over time, I started to get comfortable, added plugins that really changed my perception of Vim. From a very basic text editor, where the most advanced feature was syntax highlighting, I moved to an editor on steroids, with a real compression engine, Git integration, and lots of other tools. In short, everything I needed.

But around this time Atom and later VSCode gained popularity, particularly in the DevOps environment. I'm not going to lie to you: I tried it. It was at this moment that I understood two things: Vim, with my configuration and my plugins, was just as powerful in terms of functionality for my use and above all, Vim had changed the way I worked. When I say “changed my way of working”, it is, in particular, for a detail that will seem stupid to you: Vim is in a terminal. Coupled with Tmux it has become, for me, an ideal combo. The organization of my Gnome workspaces, my screens, in fact my entire work workflow ended up being focused on this. So I decided to return to Vim, while continuing to develop my configuration.

What changes daily

When I saw Neovim pass by, it seemed to me that it was in 0.4. At the time, I said to myself: “ah, another fork that doesn’t add much”. So, I stayed on Vim. Especially since version 8, released recently at that time, brought cool features, notably asynchronous support. I still followed the evolution of NeoVim from afar.

One day, a new version 0.5 of NeoVim was released, and this was, I think, a real argument to start considering migration. This update brought a lot of very interesting features. Of course a fully integrated client for the LSP (we will talk about it later), better support for Lua configuration,and a new parsing system for syntax coloring in particular (Tree-sitter).

In the end I ended up giving in and testing it in front of the list of its contributions:

A client for directly integrated LSP
Being able to configure in Lua: Vimscript quickly has its limits
More open: many interesting plugins are available only on NeoVim
Better documentation

Casually, a more dynamic community, often with a modern approach
I will spare you the bug fixes and little everyday joys, especially on the default settings, which are much less austere than Vi or even Vim. For many, this list must be vague and that is normal! Beyond the list, I suggest you take a quick tour of these new features, what they bring and especially how they work.

Lua

If you are a minimum advanced Vim user you have already encountered the famous VimScript, the language which allows you to configure your installation, but also to create plugins. It used to be an unpleasant point for a lot of people, including me. With Lua we have gained in comfort and possibilities.

I was a little afraid of having trouble at first having never used Lua, but it's quite clear and simple. To be more comfortable, I still took a few minutes to know the basics and for that I recommend this site.

One thing is still worth noting: you can have a lot of problems if, like me, you cut your code too much. Either way we can correct it, but personally it tired me out a lot for a minimal contribution so I put all my code in a file.

Small example of code in Lua:

function map(mode, shortcut, command)
  vim.api.nvim_set_keymap(mode, shortcut, command, { noremap = true, silent = true })
end
map('', '<C-D>', ':Telescope find_files<CR>')
map('', '<C-F>', ':Telescope grep_string<CR>')
map('', '<C-X>', ':NvimTreeToggle<CR>')

Packer

I have been talking about plugins since the beginning of the article, but using a simple editor doesn't involve doing everything by hand. So I have been using a plugin manager for a long time and if you don't, I strongly advise you to get started: it's very practical. I used Vim plug which was everything I like: simple and effective.

But with NeoVim, a whole new world of plugins is available to us. And among these plugins, one of them, very popular, allows you to manage plugins: it is called Packer and is not developed by Hashicorp.

This offers, in my opinion, everything I could expect from a plugin manager under Neovim:

Developed and configured in Lua
Manage dependencies
Lots of installation and management options
Manages installations through asynchronous tasks
Supports Git especially in terms of tags

The manager works well, allows you to install, update and delete different plugins. Beyond that, it installs easily and automatically with just a few lines of Lua code:

local fn = vim.fn
-- Automatically install packer
local install_path = fn.stdpath "data" .. "/site/pack/packer/start/packer.nvim"
if fn.empty(fn.glob(install_path)) > 0 then
  PACKER_BOOTSTRAP = fn.system {
    "git",
    "clone",
    "--depth",
    "1",
    "https://github.com/wbthomason/packer.nvim",
    install_path,
  }
  print "Installing packer close and reopen Neovim..."
  vim.cmd [[packadd packer.nvim]]
end

Installing plugins is just as simple and efficient:

require('packer').startup(function(use)
  use 'wbthomason/packer.nvim' -- Package manager
    # Put all your plugins
  use { 'nvim-telescope/telescope.nvim', tag="nvim-0.6", requires = { 'nvim-lua/plenary.nvim' } } #Plugin with a dependency 
tag
end)

To interact with Packer: you just need to use the NeoVim console to execute commands, such as PackerInstall and_ PackerSync_.

Please note: Neovim having a more regular development cycle, the plugins are also often updated. If you are not using the latest version of Neovim, do not hesitate to tag the plugin installations. I had some unfortunate surprises: plugins, which, once updated, were no longer compatible with older versions of NeoVim. This is done simply as in the example given above.

LSP

One of the weaknesses of Vim, for a long time, was the quality of comprehension, more especially of the engine which allowed the editor to understand the structure of the code in order to do autocompletion or even to notice errors. Syntactic problems and so on.

This situation has already changed thanks to Language Server Protocol and the numerous implementations based on Json-RPC.
Neovim provides a perfectly functional native client, which simplifes installation, and allow us to benefit from features worthy of the most popular editors.

It should be noted that, although Neovim integrates the client, certain plugins are necessary for LSP to give you a better integration experience. I advise you:

nvim-lsp-installer which allows you to install language servers directly from the Neovim console
nvim-lspconfig which brings together a set of basic configurations for LSP
cmp-nvim-lua which displays small windows for autocompletion.

If you want to verify that your editor has detected the language and is using the correct server, you can use the command: LspInfo, which will show you all the LSP client information.

It may happen that your editor does not associate a file type with the language server. In this case, you can specify it, as below:

require'lspconfig'.terraformls.setup{
    capabilities = capabilities,
    filetypes = { "tf", "tfvar", "terraform" }
}

Bonus tip, you can run a diagnostic of your Neovim, in order to identify certain problems. For this just run:_ checkhealth_.

Telescope, boosted fzf

Very often when you start customizing your Vim or Neovim, you install a plugin allowing you to display the tree structure in your editor. It's nice, it allows you to have a view of the structure, but moving from one file to another is slow. So, very quickly, we turn to Fuzzy-finder. And there, generally, we come back to life and we no longer want to leave our publisher.

Fzf is good, but as I said above, Neovim offers a lot of new plugins with new implementations. And among them, a supercharged fzf: Telescope! It allows you to search for files, and even text patterns, while offering an interface with file previews! A must have , quite simply.

Finally the version of Vim we have been waiting for?

When I decided to migrate to Neovim, I preferred to do away with Vimscripts, in favor of Lua. And looking back, I think it was the right approach. However, I must admit that I wasted a lot of time, particularly in wanting, at all costs, to divide my configuration files too much, which Lua obviously doesn't like. I ended up using a simple base I found online and adapting it to my taste. I still kept the theme which is a nice homage to Atom.io which I had tried.

Vim was clearly my main IDE / code editor, I hesitated to change for a long time, not being sure of the contribution. In the end, the transition is going well: Neovim is a great development, but it does not destroy Vim's heritage. We therefore find the modal system, the lightness, the native terminal operation and everything that makes Vim so remarkable.

Disable Effects of a Controller On its Pods in Kubernetes

Umair-khurshid — Fri, 21 Jun 2024 20:57:34 +0000

A controller is the name for several different elements in Kubernetes. One of these elements designates the global name of any resource responsible, among other things, for the creation and lifecycle management of the pods.

A typical controller is a Deployment, which is used to deploy pods in several replicas but is also responsible for destroying or recreating them as needed. The other three most used types of controllers are StatefulSet, DaemonSet, and Job. When working with controllers, we may want to prevent them from making changes to pods temporarily. So, how do we do it?

The cleanest solution (STS only)

In the case of an StatefulSet (STS), we have a significant difference compared to a dDeployment, it is the presence of Rolling Update Strategies, at the root of spec, of which here is the entire API with the values by default:

spec:
  updateStrategy:
    rollingUpdate:
      partition: 0
    type: RollingUpdate

What we are interested in is spec.updateStrategy.rollingUpdate.partition. This option is only available if spec.updateStrategy.type is set to RollingUpdate. It allows you to specify, in a StatefulSet, the pod ordinal above which modifications made to the controller will be propagated. In other words, with the default value of 0, all pods will be updated when the StatefulSet changes. If set to 1, then all pods will be updated except the first pod, whose name ends with -0.

This allows for canary deployment at a lower cost, such as modifying the image of only 30% of the pods to gradually introduce an update. The command to patch a StatefulSet is as follows:

sts=postgres
part=2
kubectl patch statefulset $sts -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":'$part'}}}}'

In the case of a canary deployment, we could first modify the image of a container in the pod template, then deploy the modifications gradually by regularly patching the controller and lowering the partition value step by step.

Note that this will not prevent a pod from restarting if it is deleted; it only affects modifications to the pod template. For handling pod restarts, continue reading.

Without a controller, there won't be any deletion or recreation of pods against your will. However, if you delete a controller, the pods created by it will disappear. To prevent this, you can use an option with the kubectl delete command that prevents a controller from eliminating its child pods. This option is --cascade=false (since it is true by default).

kubectl delete sts postgresql --cascade=false

When deleting a controller this way, Kubernetes still removes the ownerReferences objects from all child pods, but does nothing else. You can then, for example, delete a pod and mount its data volume in a new pod for a special operation (such as an advanced backup). Using the backup example, this method can also be used to turn off the pods of a StatefulSet one by one and take the time to perform a cold backup of the data on the storage side.

However, you should remember to recreate the deleted controller if you want to keep the pods alive after the operation. Here is a bash script that provides the basics of using this method properly:

This script ensures that the controller is recreated as is once the operation is completed or if the script encounters a problem, or if the user kills it prematurely (except in the case of a kill -9 of course).