Force all pods in a specific namespace to schedule on defined hosts with Kubernetes

Sometimes, we need to stick pods to specific hosts to isolate business critical workloads from others, or take advantage of different server types. We can do it by assigning a critical taint on a node as follows (critical can be changed to whatever you like): kubectl taint nodes node1 role=critical:NoSchedule or using kops, on a newly created critical InstanceGroup : spec: taints: - role=critical:NoSchedule Nodes having this taint won’t schedule any pods that don’t have a toleration assigned to them.

Install all firmware updates on Dell PowerEdge servers with Ansible

This feature is only available with iDRAC Enterprise License. The supported servers are : 12G and 13G PowerEdge Servers: iDRAC 7 and 8 with Firmware version and above 14G PowerEdge Servers: iDRAC 9 with Firmware version and above While looking once more for the most easy way to update Dell servers firmwares, I stepped on this awesome video showing someone from Dell use Ansible to update at once all the firmwares of a server :

Cloud-init doesn't append the SSH-key/password at first boot of an instance

If cloud-init fails to append the specified SSH-key or password at the first boot of an OpenStack instance, or changing the hostname, it could just be a simple misconfiguration of a security group. Indeed, in the default security group or within any newly created security group the following rule is added by default : Direction Ether Type IP Protocol Port Range Remote IP Prefix Remote Security Group Local IP Prefix Egress IPv4 Any Any 0.

How to use KeePassXC with ssh-agent to secure private key access

SSH-keys are the most common way to connect to a server securely and in an effortless way. A good practice is to protect the keys with a long-enough passphrase. Since it can be painful to type it every time one wants to login to a server, ssh-agent is often used to bypass this. But this can be a security caveat, since any malware or anybody who can access the laptop can then use the ssh-key to connect to servers.

How to use Terraform to deploy an Application Load-Balancer (ALB) with multiple SSL certificates

The old Elastic Load Balancer (ELB) now known as Classic Load-Balancer currently only supports one SSL certificate. Since October 2017, it’s possible to use up to 25 SSL certificates on a single Application Load-Balancer (ALB). The ALB will then use SNI to provide the right SSL certificate depending on the URL accessed. AWS Provider 1.10.0 is required, included from Terraform 0.11.4, but it’s possible to use it with an older Terraform version