Ansible 2.1 Released, with Network Automation, Containers
1–10 of 94 posts
Re: Ansible 2.1 Released, with Network Automation, Containers
#2Re: Ansible 2.1 Released, with Network Automation, Containers
#3now with extendended network support one question gets even more important: how do you do rollbacks with ansible? There is no default mechanism or policy that seems to help with that, so I have to hand-roll my rollbacks?
Re: Ansible 2.1 Released, with Network Automation, Containers
#4now with extendended network support one question gets even more important: how do you do rollbacks with ansible? There is no default mechanism or policy that seems to help with that, so I have to hand-roll my rollbacks?
Re: Ansible 2.1 Released, with Network Automation, Containers
#5now with extendended network support one question gets even more important: how do you do rollbacks with ansible? There is no default mechanism or policy that seems to help with that, so I have to hand-roll my rollbacks?
Am I missing some other detail?
Re: Ansible 2.1 Released, with Network Automation, Containers
#6now with extendended network support one question gets even more important: how do you do rollbacks with ansible? There is no default mechanism or policy that seems to help with that, so I have to hand-roll my rollbacks?
There are plenty of caveats to the above (like the fact that the yum module won't downgrade [1], and you'll need reversible DB migrations) but that's basically the procedure.
[1] https://github.com/ansible/ansible-modules-core/issues/1419
Re: Ansible 2.1 Released, with Network Automation, Containers
#7now with extendended network support one question gets even more important: how do you do rollbacks with ansible? There is no default mechanism or policy that seems to help with that, so I have to hand-roll my rollbacks?
In the event you deploy some code, a DB migration, a server configuration change, etc, and your solution fails after the fact, you move forward, not backwards. Let me explain further.
If you deploy v1.0 of your application and it works, great! If you then deploy v1.1 and it falls over, you find out why, apply a fix, test it locally (Vagrant?), deploy it to a testing environment and perform automated tests (Selenium, jMeter, ...), and once it's working there, you deploy it to production. This is called a hot fix, and it will now be working as intended (unless something else is horribly off the mark in which case you have other issues.)
The key to this example is the local and remote/network-based testing environment(s.) In my opinion, it's very much a realistic goal for ALL organisations of ALL sizes to operate local development environments using Vagrant and VirtualBox; a testing environment that spreads out the whole solution over multiple boxes (for testing networking code and configuration, among many other things); a staging environment for running performance tests (staging should match production bit-for-bit, cpu-for-cpu, ram-for-ram, ...) using jMeter or your choice of tooling; and finally a production environment to serve clients. This is the absolute minimum all organisations should be aiming for, and it doesn't even have to be fully automated using CI and/or CD.
Also tests, such as unit tests, systems tests, integration tests, usability and performance tests, and so on, are also critical to preventing the need to roll back and instead, implementing a roll forward policy.
Re: Ansible 2.1 Released, with Network Automation, Containers
#8Also, why do we have to install aptitude to do system updates ? It has been a long time since apt-get had bad resolution issues (and aptitude isn't installed by default anymore (has it ever been?)).
Re: Ansible 2.1 Released, with Network Automation, Containers
#9Unfortunately it's probably the most important python package that doesn't support Python 3, it would be cool to see it upgraded. Apparently the hold-up is supporting very old 2.x python versions because of RHEL.
Re: Ansible 2.1 Released, with Network Automation, Containers
#10now with extendended network support one question gets even more important: how do you do rollbacks with ansible? There is no default mechanism or policy that seems to help with that, so I have to hand-roll my rollbacks?
The simple answer is: you don't, you "roll forward." In the event you deploy some code, a DB migration, a server configuration change, etc, and your solution fails after the fact, you move forward, not backwards. Let me explain further. If you deploy v1.0 of your application and it works, great! If you then deploy v1.1 and it falls over, you find out why, apply a fix, test it locally (Vagrant?), deploy it to a testin…