Posts

Tech - Check your Salt - Part 3

Image
Overview In the previous post , we saw how beacons were deployed in all machines using state files. Salt internally uses zero MQ messaging for communication between the master and minions. As with any messaging framework, there are publisher(s) and consumer(s). One can think of the beacons (on salt minions) as publishers and reactors (on salt master) as consumers. Salt Concepts Covered In this post, the following Salt concepts are covered - Beacons - Monitor minions for state changes, system diagnostics etc. Reactors - Trigger reactions when events occur in the managed systems running minions. Beacons A beacon on the minion can be used to monitor various system events such as - memory usage, CPU load average, overall statistics, user commands etc. The beacon deployed in the previous post contains the 'sh' module. Sh module monitors all commands run on a machine which has the salt minion running. Note: Every time a beacon is deployed to the salt minions,

Tech - Spread the Salt evenly - Part 2

Overview In the previous post , we saw how to setup the salt master and minions. Now, let's see how we can use Salt to maintain a consistent state in the infrastructure. The state here could mean - software, configuration, permissions etc. Salt Concepts Covered In this post, the following concepts are covered - Formulas (States) - A declarative or imperative representation of a system configuration. Top File - Matches formulas and Salt pillar data to Salt minions. State Management One of the key concepts in Salt, is state management. State management in Salt ensures that the applications and infrastructure is managed centrally (as you would using other tools such as Chef, Ansible, Puppet). In addition, state management also ensures that if someone changes the configuration in a minion, state management will rest it back to what it should be. This way, Salt ensures that all changes to application, infrastructure, configuration, permission etc. are managed centrally

Tech - Sprinkle some Salt - Part 1

Image
Overview With the advent of DevOps, many tools have come up on the topic of automation. These include tools such as Jenkins, TeamCity, Ansible, Chef, Puppet, Vagrant, Terraform etc. And, they are used to deploy infrastructure and applications. However, once an infrastructure or application is deployed into an environment (Development, Testing, Production), there are changes made to it. The operations and/or site reliability teams may tweak operating system, application configuration to ensure that the environment is stable and functioning well. And, when these changes are made, the environment tends to 'drift' when compared to the source code or documentation. This is where tools such as Salt Stack are useful. It is a tool from https://www.saltstack.com . At a high level, Salt is a configuration management system.  Like most other automation tools, it can deploy infrastructure / application.  In addition, it can also monitor and react to various events. This gre

Azure Chronicles - VM Security

Using the cloud has many benefits, some of them such as elasticity and scalability. On the other hand, some other aspects such as security and cost need to be paid attention to. Let's look at the security aspect in this post. Lynis is one of the most popular Linux auditing and hardening tools. It has community and enterprise editions. As an example, the community edition is being used here. Let's scan a Linux based VM in Azure and find out the results. This post assumes that you have an existing subscription in Microsoft Azure. The below steps show how to scan a VM in Azure. A new class of VM's called B1ls was launched. These VM's are quite small and cheap. As this is just an experiment, let's try this new VM. Create a B1ls VM with the Ubunto 18.04 LTS image on it. Make sure that the VM has a public IP address and use a public key for access. Once the VM is created, login to the VM using a tool such as Putty. Follow the steps described here to ins