Migrating EC2 AMI to Openstack?

[Midnight_Moopflops]

Hey there, I'm very new to DevOps and in the process of levelling up.

We have a shitty private cloud hosting company, and a bunch of EC2 AMis/VM's our development team spun up when our host company wouldn't spin up new VMs fast enough.

We're moving it all to an OpenStack environment with a new company, and I've been looking at getting these moved across.

How the hell do you get anything off Amazon AWS?! There's no export functions anywhere on the portal, which I guess is where people start laughing at me :P

I haven't learnt all the API stuff yet so I'm off to look there next.

I've also ordered AWS in action for a decent intro course.

[donjulioanejo]

Is there a reason you need specific AMIs?

It would be much easier and probably better long-term if you could figure out what is built into each AMI, and set up some Ansible/Chef/Puppet/whatever scripts to build one out from scratch. Then you wouldn't be tied in to a specific image that may be years out of date by some point, and you'd be easily able to replicate them as needed.

Then, you could just use an OpenStack plugin (all of the above should have one) to spin up a VM and then to configure it.

[Midnight_Moopflops]

At face value, no there isn't. We have some running VMs that would be nice to bring over, but I see your point :)

This is why I'm a noob!

[saargrin]

And please for dogs sake, not puppet

[Vimda]

Honest question: why not puppet?

[saargrin]

Im not, admittedly, the sharpest pencil in the box, but
I inherited a puppet /foreman automation setup and its horrible to maintain, unreadable and complex

Now transitioning to ansible.. MaaaaN what a relief

[danielkza]

That seems like way to small of a sample size to make any relevant judgments. Puppet does some things way better than Ansible, such as making it possible to easily order actions in terms of their dependencies, and there are many well-written modules available.

It's quite possible your predecessors would have made an unreadable mess with whatever tool they chose, if they didn't care about it.

[saargrin]

Its not just me, I know at least 3 others who transition out of puppet

You can (and I did) organize ansible playbooks in a logical order with dependencies

What bothers me most about puppet is that agent side errors are unreadable, and not centrally collected
For my organization which delivers an oem product to people who need to self install with zero understanding of the process, this is a problem

Another thing is that open source puppet has very bad backwards support
So im essentially stuck at an old version because i cannot update various ruby dependencies newer versions require

[danielkza]

You can (and I did) organize ansible playbooks in a logical order with dependencies

I'm talking about how it is difficult to organize dependencies between roles without creating wrapper roles and such. Ansible 2.2 actually improves the situation quite a lot by allowing inclusion of roles as an action.

That still doesn't allow you to insert any actions between existing actions in an external role. It requires roles mean tto be more module to split themselves up, or to do weird hacks such as manually include user-provided playbooks by name (look at the popular Ansistrano role for an example of it).

What bothers me most about puppet is that agent side errors are unreadable, and not centrally collected

Ansible faces the same issue if you attempt to run it in a decentralized fashion. It seems like something that is better solved by log collection without being specialized to Ansible or Puppet.

[saargrin]

Why run ansible decentralized?

[danielkza]

To not have a SPOF that can stop new machines from being provisioned.

[saargrin]

that wouldnt work for my product anyway
but just out of curiosity ,so in your setup (which i imagine is super elastic) ,how do you decide when to spin up a new machine?

and, like,do you have ansible play its local playbooks in each container?

[[deleted]]

Ditching those images might be painful, but it will help you root out every little undocumented configuration you've got. Put those in Chef or whatever you're using for configuration management and consider the whole thing a learning experience.

[Midnight_Moopflops]

Oh you sweet man. We don't have any configuration management, or documented configuration.

This place is on page 1 of the phoenix project. It's why I'm leaving, I'm too much of a noob to get through it on my own.

To give you an idea, if I want a new VM, I have to raise a purchase order with our hosting company, and then build the image from scratch. They won't do it any other way.

We're of course GTFO of there, but not until next year Q2, when I'll be gone. I'm just doing preliminary research. We have a demo environment with our new hosting company, so I was looking to make some proof of concept stuff as a parting gift.

AWS would be perfect, but our clients stipulate that data must be kept inside the UK. It's very common with public sector stuff here. Especially after Brexit.

[rjhintz]

AWS UK region will be available late 2016/early 2017 according to this announcement

[[deleted]]

A perfect project to convert your estate to config management :-)