Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
10

In such context the typical advice should be immediately applicable: use the right tool for the job. But then you also cannot ignore nowadays the almost virulent tendency of software tools to extend functionality into more or less related fields and actually become toolsets for various reasons: cool feature(s) to have, expand customer base, amass more ...


10

Yes, F5's do support Configuration as Code. Historically, F5 has made an appliance to manage Configuration as Code called "Enterprise Manager" which pragmatically managed client endpoint F5s (LTMs, etc) using the iControl XML API. They rather quickly discovered this management appliance was terrible and added a more robust REST API to the client appliances ...


8

There is definite value in automating manual tasks and placing systems under configuration management that is done using code, not using paper and human intervention. One huge benefit is the reduction in the amount of rework. You can consider any problem caused by a human mistake in repeating the same sequence a case of rework. As well as any bug that needs ...


8

This is a simple thumb rule one could follow Use version control (git, svn, cvs) for the work product created by humans Use artifact management tool (artifactory, nexus, apache archiva) for the software bundle (artifacts) created by the system thru build or packaging process HUMAN ==> System GIT/SVN (build/packaging) ...


8

The two terms are very different. Let us start with immutability, which literally means "no mutations" or "no changes". In the DevOps sense, it means that once you created an artifact, be that a container image, or a VM image, or maybe a package from compiled code - you declare that you will never ever change it. Often if any changes are required, you ...


7

Since "deployment" to the IoT device, especially in bulk, will not be done using the CI system. Then the purpose of the CI system is mostly to make sure that it will work okay. This means that you mostly want to run some tests using the CI. Automated testing is definitely possible, both for unit tests and for integration tests. The most important thing for ...


6

Version Control (using say git) and Artifact Management (using Artifactory) are complementary. Version control is useful for easily browsing the historical changes and who made them. Artifact management tools can do this but its clunky. Also they dont offer a fine grained view of changes, as one version change might involve a large amount of changes. When ...


6

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,...


6

Configuration management tools are used to get a system into a known state. Deployment tools deploy new program files and program data to a system. At the end of the day, both types of tools do some combination of: Determine the current state of the system. Transfer files to the system. Add or change persistent data (e.g. configuration files, database data,...


6

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" assert: that: cluster_name|len <= 6 In Puppet: there is fail function evaluated during parsing phase which cause parsing ...


6

The tool you need is Packer using Docker as the "builder" and Chef as the "provisioner". Then you can add the resulting image to your repo and reuse it without having to pack again, until your recipes change.


6

if I setup automate deployment of code, is this considered devops? Sure, automating everything is a big part of DevOps. I tried ansible but I prefer writing my own code for learning Now, this is laudable, but using Ansible (or Puppet or Chef or ...) would be "learning" as well. The benefit of using established tools over DIY is that if/when you meet ...


6

A good way to find comparison information about things like this is googling for "X vs Y", e.g. "Chef vs AWS stacks", "Chef vs Puppet" or something like that. That does turn out subjective information, and while it is nothing like having hands-on experience, you still get a few nice nuggets here or there. For example, Chef gives you the full Ruby language ...


5

This turns out to be a known issue: The require_in requisite does not support everything that require does, mainly id does not support sls or state_id without specifying a state module. So by modifying our SLS file to include the state module (specifying file: /root/b as the require_in target instead of simply /root/b), we get the correct result. I don'...


5

The direct answer is "no". Ansible does not have any database, because it is supposed to be run by different operators from different computers and it's purpose is to be sure that target systems are in the exact state, as specified in playbooks. There's an option to attach external facts cache backends to Ansible. So you can setup redis as your cache, ...


5

So let's imagine you have 20 microservices, each in a separate repository. Each microservice needs to be deployed into 5+ environments: dev local, dev cloud, test, staging, prod. Understandably all configuration will be different in each environment. However, you don't need to put it into the Dockerfile - in fact you don't put any configuration into the ...


4

TL;DR: Just use Ansbile, it is both configuration and deployment tool :) There are several types of deployment: Application based (files, archives packages) Container based (includes VMs, Habitat, LXC, Docker) Function based (Micro services / Lambdas / Functions) I assume in this case we speak only about application updates on server(s). For deployment ...


4

The main advantage to automation isn't just automation itself, but also that it provides you with an identical configuration across all of your resources. Say, for example, you stand up a webserver hosting your application and all relevant configs. Then you register it as an Amazon AMI so you can deploy multiple copies (say, one for dev, one for test, and ...


4

You can only insert the return into the mine. Just specify the cmd.run (or possibly cmd.script) in your mine_functions and you will get the whole return back. If you want to have a script that sets up extra config on the minion, I would recommend writing a custom grain. https://docs.saltstack.com/en/latest/topics/grains/#writing-grains


4

One of the things I have the hardest time getting across to people is that the man-hours saved doing repetitive tasks is often only a small part of the value of automation. The bigger part is often hard to measure, and nearly impossible to estimate when automating something for the first time: how it changes the way you work. Talking with developers, this is ...


4

I'd go with node.run_state to store a transient variable in a run and define it in a ruby_block so it happens at converge time, something like this: yum_package 'somepackage' ruby_block 'set myvar' do block do node.run_state['my_var'] = Mixlib::ShellOut.new('/bin/somecommand').run_command.stdout.strip end end As far as I know requiring 'mixlib/...


4

AFAIK Kickstart is only usable for the initial installation of the OS, but not for subsequent package maintenance upgrades/downgrades. Unless I miss something (quite possible, I don't have much experience w/ them) the Linux distros managed by configuration management tools require a minimum level of health from the OS (and some package requirements, at ...


4

James, you are correct in that BIG-IQ replaced Enterprise Manager. However, like Enterprise Manager, BIG-IQ is for 'device/feature' management. For integrating via REST APIs directly, or to 3rd party automation tools/tool-chains, you should look at F5 iWorkflow (programmable/extensible API gateway). The team behind iWorkflow are focussed on 'services ...


4

These strategies have nothing to do with one another. Containers (like Docker) are a methodology for deploying and isolating applications. Containers are well liked because they're transportable. They can be developed on and previewed locally in most cases, so putting applications in them makes sense. As for why Docker uses shell scripting: A docker image ...


4

One consideration might be lock-in. For example, Amazon's cloud can become expensive very quickly - either because compute ends up being more than you estimated or there is always the possibility that Amazon decides to raise the cost of their compute price. This could cause you to want to change cloud providers to a cheaper one or perhaps you scale to a ...


4

I have never heard of a common name for what you describe; and rarely, if ever, have I seen a notation where someone references to something which has a "begin" and "end" version. It just is not that applicable in a general fashion; this is probably why there is no such name. Also changelogs usually don't contain this information except for extremely bad ...


4

The reason; having a more a version-agnostic and more backward-compatible directive in my server-environment-establishment script, to change the values of these two variables. If you're trying to configure a server, you should use a configuration management system (Ansible, Puppet, Chef, Salt) or bake images for immutable infrastructure; trying to hack ...


3

The answer is that you can't directly. You have to set a grain on the minions first by doing something similar to: salt '*' cmd.run 'grep environment /etc/salt/minion | awk "{print \"environment: \" \$2}" >> /etc/salt/grains' salt '*' saltutil.sync_grains salt -G environment:prod cmd.run 'df -h'


3

SaltStack provides a method for modifying grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file. For example: 1. add grains to the minion config. Note, simply include the grains key here: id: minion-07 grains: roles: - ...


3

Pros: No configuration management tools like puppet, chef, salt or ansible needed Cons: Dependent: If one has written a lot of NixOps files and one decides to go to another provider then one has to rewrite all the provision scripts, while a tool like terraform is cloud agnostic No autoscaling like docker Promotion of silos, e.g. DevOps friendly. In my ...


Only top voted, non community-wiki answers of a minimum length are eligible