Some options out there..
Testing tools: Sorted by github stars
Serverspec - Ruby, most popular tool out there, built on ruby's rspec
Goss - YAML, simple, <10MB self-contained binary, extremely fast, can generate tests from system state
Inspec - Ruby, think of it as an improved serverspec, almost same syntax, made by the chef guys. Built to be easier to ...
The two tools I've seen for this are InSpec and ServerSpec. Serverspec is a Ruby-based tool that builds on RSpec. InSpec is inspired by RSpec and ServerSpec.
I've used ServerSpec. It's cool, but maybe not 100% stable. I've had problems with testing for specific versions of software on Ubuntu.
I've read the InSpec docs but haven't dug in deep. It does ...
I've had two runs at doing environment variables in a scalable way and neither has ended up perfect because, as I've discovered, is a very tricky thing to get right. I'll give a summary of both of my experiences below:
Environment variables are stored in a separate repository from the original source code (they are submoduled together but ...
One of the implementation on code is the Pull Request model (PR) popularized by GitHub.
The main reasoning behind is that only a small set of maintainers of the product will be allowed to merge code into the release branch. Every new feature/bugfix will happen on a new branch and once done will be defined as a pull request.
This allows to test on the ...
When using configuration management tools, such as Ansible, the tool itself would be responsible preventing configuration drift. Once you used Ansible to set a certain configuration, repetitive execution of Ansible will ensure your configuration is as you defined it to be. This also requires your Ansible code to be written in a manner which is idempotent.
This is about having at least 1 other person look at the code written by somebody, eg to evaluate if it meets some predefined criteria like:
Coding standards (indentations, etc).
Maintainability of the code.
Completeness (eg if/then/else or case/when constructs cover all possible cases).
Approvals to ...
In the SCM-world where I'm mostly familiar with, the above scenario is typically addressed by what's called the "abbreviated-approval list procedure.
Here is a blueprint of it:
Define your business hours, say from 8 am to 6 pm.
Define a complete approval list of (say) 3 levels of approval (for roles X, Y and Z).
Define an abbreviated approval list of (say) ...
There are many tools that can do something like this, including configuration management tools like Chef, Ansible, or Puppet; and KVS tools like Consul and etcd. You could also integrate it as a build step in your CI server, or sidestep the issue using live configuration at runtime against an external configuration store (again, something like Consul or etcd,...
In Ansible: you can use assert or fail module.
- name: "Make sure web_sites is dictionary"
fail: msg="web_sites should be dictionary"
when: web_sites is not dict
- name: "cluster_name should be shorter than 6 chars"
that: cluster_name|len <= 6
In Puppet: there is fail function evaluated during parsing phase which cause parsing ...
These are strategies/patterns I can think of:
Separation of Duty
DevOps, to my view at least, does not means embodying of both dev and ops in a single person. So it is still possible to separate the duty such that the one writing the code (dev) is not the one executing it (ops).
For example, if an SQL statement is to be executed on the live environment, ...
Test Kitchen has a kitchen-ansible provisioner plugin for testing of Ansible code. It isn't as deep as the Chef integration but it does get the job done for most cases. There is also the more recent Molecule project which is a dedicated Ansible testing system.
Who said that properties files and environment variables where mutually exclusive?
There is a distinction to be made between "where do I store my app configuration?" And "where does my app source it's configuration? "
The most likely outcome is that everyone probably should just keep doing what they are doing with configuration files as a storage mechanism ...
How about user-data ?
I believe adding the "#cloud-boothook" allow to force the user-data to run at every restart.
echo 'test' > /home/ec2-user/user-script-output.txt
If so, you could fix your sudo scripts hopefully... or install / add AWS run commands configuration https://aws.amazon.com/blogs/aws/new-ec2-run-command-remote-...
Generally recovering from this sort of mistake involves editing the boot loader to force a root shell. Since you don't have physical access to the (non-physical) machine, things are a bit different.
If this is an EBS boot drive, you can try detaching it, fixing it on another machine, then reattaching.
This is a good opportunity to learn why it's useful to ...
TeamCity has a Shared Resources build feature which allows you to define a resource which multiple Build Definitions depend upon it. Build Definitions can either require a Read Lock or a Write Lock, you can also define if these locks are exclusive or allow a degree of parallelism.
If we make the following assumptions about a shared environment named ...
The best solution we found so far, is using the MagicalGoConfigXmlLoader interface from the go source code, as it calls an internal validateCruiseConfig command, that does all validations, or die if the file is invalid:
MagicalGoConfigXmlLoader loader = new MagicalGoConfigXmlLoader(new ConfigCache());
The main ...
In the case of off-hours emergency fixes, it's more practical to require less sign-off for changes than your normal procedure. Generally, you can deploy a fix and then do post-approvals the next business day. If the fix is not approved, it can be reverted and replaced with a permanent solution.
During an outage situation, the number one priority should be ...
Yes, I do believe so. To explain that I need to lay some groundwork on how I have implemented something similar, I have simplified the model in an attempt to make it as clear as possible.
I am making the assumption here that Jenkins, TeamCity or similar is being used as the CI/CD tool of choice. Additionally GitHub is being used and that there ...
My answer in the context of the question is a very expensive test environment (like mainframes or very large telecom equipment, for example) which are expected to be shared by multiple users for multiple tests, even simultaneously.
In many cases such equipment has a software management system responsible for, among other things, controlling software (un)...
If your environments are per customer, I would suggest in your specific case to have a repository per customer. (In general it is repository per environment.) This repository would have a standard directory structure for environment variables, ansible variables and inventories, strongly encrypted secrets (account access tokens, private keys, etc.). You ...
After looking a bit further, I found it in the sample called filebeat.full.yml
So I added this section to the filebeat.yml
After running at 100% CPU for minute, Kibana is now immediately showing the results. That was easier than I expected.
#========================== Modules configuration ============================
As mentioned in the question and the comments on it, this isn't an area in which Ansible excels. The "best" solution depends a bit on the type of file you're dealing with, and the structure of it.
The cleanest way to deal with these sorts of changes in Ansible is to templatize the entire thing; this allows you to see the entire file at once, rather than ...
Personally I'd keep them in separate repositories, for clear customer isolation:
minimal/no risk of unwanted interference between customers
different access control for different customers is possible
different CI/CD pipelines and/or configs for different customers is possible
simpler/standard CI/CD configurations
clean per-customer repository history
What approaches are there to manage multiple package.json files that live in each feature directory
One could leave the package.json in every feature directory and let the CI read the package.json when building the app. One could define the versions of dependencies in the package.json to get control about the app. If the app works with version A.B.C of a ...
State and pillar environments are set independently.
in the minion configuration will force the minion to use the prod state, but it will still use the default pillar data. To select a pillar environment you will also need:
This also does not work in old versions of salt and is only supported with pillar.get ...
One could pass environment variables when running docker, e.g.:
Additionally, the operator can set any environment variable in the
container by using one or more -e flags, even overriding those
mentioned above, or already defined by the developer with a Dockerfile
$ docker run -e "deep=purple" --rm ubuntu /bin/bash -c export
There are currently 5 dunder dictionaries. They are available at runtime and generally not stored statically.
__opts__ - Master or Minion configuration options; stored in configuration files of master and minion, collected at startup
__salt__ - Execution module functions (i.e. __salt__['test.echo']('foo')); from built-in and custom execution modules ...
Well, that's pretty broad, mostly this can boils down to two options:
Policy based management
In the first one you're describing the actions you want to be done to achieve the desired state, assuming previous state of the system or testing against it specifically, in the second you're describing what you expect as resulting state of the ...
I think that according to chef documentation you should use normal with node data.
A normal attribute is a setting that persists in the node object. A
normal attribute has a higher attribute precedence than a default
you can read about it here: