pupperware experience and Console UI?

[Michael Gale]

Hello,

    Currently we run the latest LTS release of Puppet Enterprise in our Dev, QA and Production environments and have an automated installation of PM Enterprise working but are finding that process to be slow. This is particularly painful in Dev/Test environments were PM installations are constantly rebuilt.

I found Puppet Docker images are available here: https://github.com/puppetlabs/pupperware and am considering switching over. 

Has anyone used these containers before and can share their feedback? I am not looking for Docker pros and cons. I am more interested in Puppet operations, upgrade issues, etc.

Also am I correct in assuming that the Console GUI found in Puppet Enterprise is an Enterprise only feature and I would need to find a replacement for that component?

Any feedback is appreciated. 

Thanks

Michael

[Ben Ford]

This is particularly painful in Dev/Test environments were PM installations are constantly rebuilt.

What are you testing in these environments? Eg, are you testing the deployment of new infrastructure, including PE, or are you testing the Puppet codebase? It might not be worth it to build & rebuild the master each time.

That said, if you're not testing Enterprise features, then Pupperware is totally usable for that purpose. I know several people who do similar things, including one person who fires off a ton of containerized agents in a Gatling-style load test.

And you are correct that the Pupperware stack is just the Open Source stack right now. The team is also evaluating the feasibility of supporting Enterprise too, but there's not a clear timeframe yet. What would you use them for in your workflow?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/270c9d2e-dc9f-4b64-9436-af0c9bbc1b29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Gale]

Hello Ben,

   Currently we have the expectation that changes should be tested in a pre-existing environment and fresh environment. In our CI pipeline we build a few different types when changes are merged in. When a change is made via git commit 1/2 the environments are destroyed and rebuild from scratch to ensure they work properly and the other 1/2  of the environments, lets call them stable have the changes applied. 

The changes to the stable are faster but I still find them slow personally. 

Changes to our environment can include any of the following:

1. - infrastructure changes via Terraform
2. - Changes to the Puppet Master before Puppet is installed
3. - Puppet Master changes via Puppet itself
4. - Puppet codebase changes

We use r10k to pull in all of the changes for the Puppet codebase. If the changes are to the codebase only then testing is easier however changes to the first 3 options usually require a stable and fresh build. 

I was looking into the container option because I think it has the following benefits for us:

1. Faster startup times for testing environments - Installing the PM Enterprise is a slow process.
1. As we move more to AWS we would prefer that every developer has their own AWS account for isolation
2. This means more Puppet Masters, having smaller containers that can be controlled via container registry would be easier to manage.
2. Less Puppet Master changes to manage between environments, for example if there a gem updates and PM master changes we currently need to add that to the build process and ensure it is managed across all environments.

Thanks

Michael

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACkW_L6eTgK1HmOCjxgs7CD514n9i%3Dvnw1o08OrOOu3Pq08JQA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

“The Man who says he can, and the man who says he can not.. Are both correct”