Posts categorized “automation”
This post offers a small taste of Dutch history but, more importantly, an overview of how to user Azure DevOps to create a CI Pipeline for Hugo!
One of the things I love about working with Cloud is the various ways you can fit together different services to perform complex business functions in a relatively straight-forward manner.
On-demand infrastructure, with its speed, agility, efficient use of resources and lower costs drives many organizations toward cloud adoption.
When used in conjunction with tools like CloudFormation or Terraform, users are able to provision and remove cloud infrastructure programmatically. This is typically referred to as Infrastructure as Code, or IaC, and is great for stateless resources.
However, what if some servers cannot be regularly re-provisioned from scratch? Does it mean they need to be up and running 24/7, even if only used during limited hours?
Terraform has gained a lot of popularity in the last couple years. Rackspace
prefers to use Terraform to quickly spin up new architecture in AWS and Azure.
However, with Amazon's lightning-fast deployment of new features, it has become
harder for the Provider maintainers to keep up. Developers are left waiting for
new features to be developed and merged into the
master branch before becoming
available for general consumption.
This blog explores the fundamentals of Load and Performance Testing as well as the basics of the Gatling Tool (https://gatling.io). Some popular testing tools are also introduced here for load and performance testing, stress testing and web application monitoring.
Our customers require us to develop software that is trustworthy and secure. Privacy also demands attention. To ignore the privacy concerns of users is to invite blocked deployments, litigation, negative media coverage, and mistrust. The Quality Engineering (QE) Security team’s goal is to minimize security- and privacy-related defects in design, code, documentation, and to detect and eliminate these defects as early as possible in the software development life cycle (SDLC). Developers who most effectively address security threats and protect privacy earn users’ loyalties and distinguish themselves from their competitors.
In Rackspace's VMware Practice Area, we value the quality of our products very much, and we believe that quality is a team effort. The Quality Engineering (QE) team works with the Development team, Project Management team, Product Engineering team and DevOps team to improve the quality of developed products. Our quality standard has three key pillars: functionality, performance, and security. Our goal is to identify and fix defects as early as possible so that we can deliver secure functional products that perform well for our customers.
Ansible development is fast, and anyone using Ansible extensively has most likely come across an instance where a playbook that used to work does not work on a later Ansible version. Or, a system that wasn't supported initially is now added and an existing role requires modification to make it work on the new system. See Molecule for Ansible role creation for more details on using and debugging Molecule. Creating a Molecule scenario to test an existing role allows for easy testing and modification of that role with all the benefits that Molecule provides.
In our Quality Engineering organization, we create, configure, and destroy a lot of servers via automation. Ansible is a great method for handling the configuration of servers, but the creation of Ansible roles and playbooks can be trial and error for even experienced Operations Engineers. Molecule provides a way to speed up the development and confidence of Ansible roles and playbooks by wrapping a virtualization driver with tools for testing and linting.
Using Terraform with Rackspace Public Cloud
Handling a huge scale of infrastructure requires automation and infrastructure as code. Terraform is a tool that helps to manage a wide variety of systems including dynamic server lifecycle, configuration of source code repositories, databases, and even monitoring services. Terraform uses text configuration files to define the desired state of infrastructure. From those files, Terraform provides information on the changes to be made based on the current state of that infrastructure, and can make those changes.
The Threat and Vulnerability Analysis team at Rackspace is charged with providing internal vulnerability scanning, penetration testing, and red/purple teaming capabilities to reduce cyber-based threats, risk, and exposure for the company. One of our tasks, as part of meeting certain compliance objectives, is to ensure systems are not exposed from various networking "perspectives" without going through a bastion first.
A common technical challenge for developers, operations, and IT security is the management of service account credentials used by applications. Service accounts are needed to authorize different components for communication and sharing data. This is true whether the application runs in the cloud or on-premise. The problem is that these credentials have the following issues:
- They are setup one time.
- They never expire.
- They are hard-coded into configuration files.
I want to share some design thoughts on how to make changing credentials easier.
A few months back, I decided to find a way to lighten the load of ad-hoc vulnerability scanning requests by our system owners. Our most frequent requests used to go something like this: "Can you scan this"..."Ok I fixed it, scan again."
Given the prevalence of Slack and associated bots, I thought it would be a good idea to try to write my own for scanning. Enter the InsightVM Slack Bot!
There are many ways to approach the broad topic of "security automation". After repeatedly trying new approaches, evaluating them against my assumptions and goals, and modifying them as I learn new things, I've come up with a number of helpful insights. I hope you find them useful in thinking about your own security automation goals.
Automation in Windows has historically been a challenge due to lack of built in tools for remote management. In the past few years, the enhancements to PowerShell and WinRM (Windows Remote Management) have forged a path that is now more on par with other operating systems in regards to remote access.
OpenStack SDKs exist for several programming languages, including Python, Go, Ruby, and many more. For those who don't wish to write code, users in the *nix world can use Curl at the command line to perform operations.
What about Microsoft Windows administrators? Are they required to learn linux and bash and curl? What if they could use the skills they already have, or learn new skills that are native to the Windows environment, for OpenStack administration? Is there a command line or scripting tool that suits the Windows DevOps world?
Having spent my last 7 years concentrating mainly on Linux® and related technologies, I spent 3 days with PowerShell and here are the some observations and anecdotes. Why PowerShell? Curiosity for one and I wanted to learn it from a perspective of how to use it in configuration management tools like Chef. As an disclaimer, I'm not an expert in PowerShell and spending 3 days is just scraping the surface but I did learn quite a bit in that time. Also my prediction is that PowerShell will be real force (if not already) in Windows environments. It is a mindset change for several Windows administrators who have grown up on GUIs but that is about to change in the coming years. And if you are Linux administrator, you are likely to feel more comfortable interacting the PowerShell way. I definitely did.
Maintaining hosts files on standard *nix system has been traditionally done by hand. This becomes a challenge as the number of systems grow and this is more true in the Cloud model where you might add/delete servers at a higher rate. One solution would be to use DNS and use a local zone to store your host name to IP mapping. If you are in the automation using Chef world, here is another example on how to automatically generate the host file entries.