Ansible under Windows with crutches, props and integration with Vagrant
It so happened that on our project Ansible is now used. I will not dwell on what Ansible is, how to prepare it and what to use it with, and also on why it is used (for this is not the best choice for operating conditions under Microsoft OS) I suggest to consider in the context of this post it is a given. It is also not a secret for anyone that a lot of web developers work under Windows for various reasons. The reluctance to fight Linux, lack of money for poppy, tanchiki after work, corporate policy - there could also be reasons for the car. And about them in this post, too, will not be a word.
If the circumstances are such that you need to use Ansible under Windows (which, in principle, is not so stressful, although it is not described anywhere else properly) and, good, integrate this business with Vagrant under Windows - I ask for cat.
')
I will begin, perhaps, with the warning. If you choose Provisioner to automate the deployment of project infrastructure and as a master you want to use your workstation on Windows and only it - better not use Ansible. Here is what is written in his installation documentation : “Currently Ansible can be run (installed) (installed).” Everything described below is a system of crutches and supports in case of emergency. And if, however, an extreme case has come or you are not looking for easy ways, let's go.
In general, there is nothing surprising. If the subject does not support Windows out of the box, but normally works only under * nix - you can try to set up a small * nix in Windows using Cygwin. Moreover, you can google already ready instructions on how to raise Ansible under Cygwin, but I managed to do it, I think, simpler and cleaner than, for example, the author of this instruction .
Looking ahead, I’ll say that for me it was the first experience with Cygwin (I myself have been on Linux for a long time, this instruction as a whole - an attempt to let the team work with a tool that was rashly chosen without a discount on Windows) and installing packages there a thing not quite obvious to me. I had to google it: it turns out that to install a package, you need to find it in the list, click on this icon
- then its status will change; To add or remove packages, you need to run the installer and go the same way as during the initial installation.
Another note. If you are from Belarus, use the mirror of Beltelecom (http://ftp.mgts.by/pub/cygwin) - by experience, this is the only way to install everything quickly. To do this, enter the specified address in the field under the list of mirrors and click Add, then select it in the list.
When installing Cygwin, select the following packages:
Optionally - gcc-core from Devel, then some Python modules will be assembled from source code in C, otherwise it will be left to be satisfied with the Python implementation.
What explains this set? It is normal to put Ansible only through the Python package pip manager, and it does not work without libuuid-devel, at least on the x86_64 version of Cygwin. binutils allows pip to use the cygwin implementation of libuuid. The rest, I think, is understandable - for Ansible himself.
Immediately after installing Cygwin, I recommend explaining to him where your home directory is. By default, it will use some sort of its own folder; using a user folder in this capacity seems to me somewhat more understandable and transparent; In addition, it solves some problems that occur when starting from under Cygwin Vagrant - without additional shaman passes, it will constantly re-create the virtual machine.
This can be done with the following command executed in Cygwin:
With strapping finished. Now Ansible itself. Everything is unexpected just a couple of teams in Cygwin - and you're done:
Why 1.5.3, ask? This is the latest version at the moment, working under Windows and not having some annoying bugs.
In addition, you need to explain to Ansible that you do not need to use an ssh feature like ControlMaster (it does not work under Windows). Its essence is as follows: ssh establishes a connection with the host, creates a socket and does not kill it for some configurable time. The next time he connects, if possible, he uses this socket (already established connection) in order not to reinstall it and Ansible works without the overhead of setting up the connection for each task. This can be done through the environment variable:
In general, that's all. After that, from Cygwin you can use the
In theory, Vagrant integrates with Ansible nicely and transparently. But not under Windows. When you first try to run vagrant provision with Ansible as a Provisioner for Windows, you will get some kind of intricate error. The reason is quite simple: Ansible will only work under Cygwin. I did not manage to find an easy way to force vagrant to call it. It would seem that the trouble is great: to build a batch file called ansible-playbook.bat, which will launch the already real ansible-playbook in Cygwin, put it in
Vagrant under Windows is the same system of crutches and supports with its bash and collection of * nix utilities. Accordingly, simply writing
As a result, through trial, error and prolonged suffering, this batch was born. It may be disgusting, but I didn’t have any knowledge of Windows scripting, so I was blind from what was, following the methodology of StackOverflow Driven Development.
Also in the process it turned out that this is the best place to set the environment variable
This .bat assumes that the Cygwin bin is added to
As a result, all of the above described was literally put in quite a few brief instructions in the steps of the project deployment and was more or less successfully tested on the new developers who came to the project at various levels.
If the circumstances are such that you need to use Ansible under Windows (which, in principle, is not so stressful, although it is not described anywhere else properly) and, good, integrate this business with Vagrant under Windows - I ask for cat.
')
I will begin, perhaps, with the warning. If you choose Provisioner to automate the deployment of project infrastructure and as a master you want to use your workstation on Windows and only it - better not use Ansible. Here is what is written in his installation documentation : “Currently Ansible can be run (installed) (installed).” Everything described below is a system of crutches and supports in case of emergency. And if, however, an extreme case has come or you are not looking for easy ways, let's go.
Installation
In general, there is nothing surprising. If the subject does not support Windows out of the box, but normally works only under * nix - you can try to set up a small * nix in Windows using Cygwin. Moreover, you can google already ready instructions on how to raise Ansible under Cygwin, but I managed to do it, I think, simpler and cleaner than, for example, the author of this instruction .
Looking ahead, I’ll say that for me it was the first experience with Cygwin (I myself have been on Linux for a long time, this instruction as a whole - an attempt to let the team work with a tool that was rashly chosen without a discount on Windows) and installing packages there a thing not quite obvious to me. I had to google it: it turns out that to install a package, you need to find it in the list, click on this icon
- then its status will change; To add or remove packages, you need to run the installer and go the same way as during the initial installation.Another note. If you are from Belarus, use the mirror of Beltelecom (http://ftp.mgts.by/pub/cygwin) - by experience, this is the only way to install everything quickly. To do this, enter the specified address in the field under the list of mirrors and click Add, then select it in the list.
When installing Cygwin, select the following packages:
- binutils (from devel)
- libuuid-devel (from libs)
- python (from Python)
- python-crypto (from Python)
- python-setuptools (from Python)
Optionally - gcc-core from Devel, then some Python modules will be assembled from source code in C, otherwise it will be left to be satisfied with the Python implementation.
What explains this set? It is normal to put Ansible only through the Python package pip manager, and it does not work without libuuid-devel, at least on the x86_64 version of Cygwin. binutils allows pip to use the cygwin implementation of libuuid. The rest, I think, is understandable - for Ansible himself.
Immediately after installing Cygwin, I recommend explaining to him where your home directory is. By default, it will use some sort of its own folder; using a user folder in this capacity seems to me somewhat more understandable and transparent; In addition, it solves some problems that occur when starting from under Cygwin Vagrant - without additional shaman passes, it will constantly re-create the virtual machine.
This can be done with the following command executed in Cygwin:
mkpasswd -l -c -p "$(cygpath -H)" > /etc/passwdWith strapping finished. Now Ansible itself. Everything is unexpected just a couple of teams in Cygwin - and you're done:
easy_install pippip install ansible==1.5.3
Why 1.5.3, ask? This is the latest version at the moment, working under Windows and not having some annoying bugs.
In addition, you need to explain to Ansible that you do not need to use an ssh feature like ControlMaster (it does not work under Windows). Its essence is as follows: ssh establishes a connection with the host, creates a socket and does not kill it for some configurable time. The next time he connects, if possible, he uses this socket (already established connection) in order not to reinstall it and Ansible works without the overhead of setting up the connection for each task. This can be done through the environment variable:
ANSIBLE_SSH_ARGS=-o ControlMaster=no or via the Ansible config, indicated in the [ssh_connection] section of the ssh_args = -o ControlMaster=no option. On stackoverflow you can find some information on this topic .In general, that's all. After that, from Cygwin you can use the
ansible-playbook as in * nix.Ansible with Vagrant: Atmosphere
In theory, Vagrant integrates with Ansible nicely and transparently. But not under Windows. When you first try to run vagrant provision with Ansible as a Provisioner for Windows, you will get some kind of intricate error. The reason is quite simple: Ansible will only work under Cygwin. I did not manage to find an easy way to force vagrant to call it. It would seem that the trouble is great: to build a batch file called ansible-playbook.bat, which will launch the already real ansible-playbook in Cygwin, put it in
%Path% so that Vagrant gets on it - just something! But it was not there.Vagrant under Windows is the same system of crutches and supports with its bash and collection of * nix utilities. Accordingly, simply writing
bash will not work: Vagrant will dilute the %Path% path to its directory with * nix-utilities (by the way, GitBash is the same sinner), and we need Cygwin and its utilities.As a result, through trial, error and prolonged suffering, this batch was born. It may be disgusting, but I didn’t have any knowledge of Windows scripting, so I was blind from what was, following the methodology of StackOverflow Driven Development.
Also in the process it turned out that this is the best place to set the environment variable
ANSIBLE_SSH_ARGS mentioned above. It is inconvenient to set it in the config, because Ansible doesn’t merge the configs, but takes the first one found - respectively, either you don’t manage to use the Ansible config in the context of the project, or you have to set this parameter for everyone, even for those who don’t need it (and turn off ControlMaster greatly slows down the delivery). It could also be specified in the Vagrant file, but then without additional bouncing it would not have been possible to use the ansible-playbook without Vagrant.This .bat assumes that the Cygwin bin is added to
%Path% (no matter which part), and the path to the batch file itself is added to %Path% before the Cygwin bin.As a result, all of the above described was literally put in quite a few brief instructions in the steps of the project deployment and was more or less successfully tested on the new developers who came to the project at various levels.
Source: https://habr.com/ru/post/224047/
All Articles