Storing Virtual Machines as Kubernetes resources in git for automated deployment promotes consistency, resilency, and accountability, but commiting secrets to git is risky and should be avoided. Use the External Secrets Operator to securely store cloud-init and other data, and sleep soundly!
The OpenShift Machine Configuration Operator applies configuration changes to to nodes using a syntax called Ignition, but managing base64 encoded text can be challenging. What if I told you that you can use plain text and normal files?
OpenStack enables automated creation of resources such as networks, routers, and servers using Heat Orchestration Templates. If you are new to OpenStack and are using a TripleO based distribution you may have seen them up close and personal without knowing it. What follows is a very basic exploration of Heat.
Heat templates are written in YAML format, and you can quickly see from the documentation that a basic template will likely have 4 sections:
OpenStack supports “provider” networks, which are networks that pre-exist in your physical infrastructure and are “provided” to the cloud users rather than created by the user. Only an admin is permitted to create a provider network.
A prequisite is the provider network must be plumbed to the external bridge on your controller and nova nodes.
Here is an Ansible playbook to create a project, place a unshared provider network and subnet in that project. Afterwards we will grant access to the members of this project using the openstack client. It does not appear that Ansible has a OpenStack network RBAC module at this time.
This playbook is written for RHEL 7.2 and OSE v3.1. It will perform the following steps which should take place before running the openshift-ansible byo playbook.
See my Testing OpenShift Enterprise V3 post for the prereqs.
The lastest version is available here.
You just deployed a complex multi-host app using Ansible. Wouldn’t it be helpful to see a overview of the deployment including hardware details?
I just found ansible-cmdb which combines info from the Ansible inventory and discovered facts to create a detailed HTML report akin to a Configuration Management Database.
To use it in your playbook dir, just create a directory to hold facts discovered by the setup module then generate the report.
The OpenShift Origin project provides Ansible playbooks and roles for installing OpenShift on various infratructure. I’m going to try out the example using Vagrant and VirtualBox on my Mac. I’m not very familiar with Vagrant or OpenShift v3 yet, so I’m just going to think out loud and see how it goes. I’ve also recently started testing OpenShift Enterprise.
OpenShift Origin is an opensource PaaS (platform as a service). It is the upstream project for Red Hat’s OpenShift Online and OpenShift Enterprise. Version 3 of the OpenShift platform is a complete rewrite just launched in June 2015. It now utilizes Docker as the container engine and Kubernetes as the orchestrator. The Enterprise edition uses Red Hat Atomic Enterprise Platform as the underlying OS. The example used in this post will create Vagrant CentOS boxes.
So you found Ansible, and you were all Woah! Ansible is awesome! Ansibilize all the things! Then you created a git repo and started hacking.
Playbooks look in the current directory to find roles, libraries, and inventories, so naturally you put everything in one big git repo, right?
You tried to follow the best practices for writing playbooks, you created roles, and maybe you wrote a filter plugin or a custom module for configuring an application unique to your environment. Eventually you wound up with a big repo of playbooks and inventory files and buried roles and realized there must be a better way to do this.
Starting with a jumbled git repo of various Ansible roles, playbooks, inventories, group_vars, etc. I want to create a new repo out of a selection of the subdirectories and retain the commit history.
I have an ansible-test repo with a tree that looks roughly like this:
.
├── adhoc/
│ ├── rolling-reboot.yml
│ └── scripts/
├── README.md
└── runtime/
├── roles/
│ ├── foo-role/
│ └── zimbra/
│ ├── ansible.cfg
│ ├── hosts
│ ├── tasks/
│ └── ...
├── group_vars/
│ ├── foo-group
│ └── zimbra-prod
├── hosts
├── host_vars/
├── library/
│ ├── foo-lib
│ ├── zmlocalconfig
│ └── zmprov
├── foo.yml
└── zimbra-playbook.yml
I want to split that so that the Zimbra role, it’s playbook, and any ‘runtime’ context like group_vars, and libraries are managed together in a new repo called playbook-zimbra.
Copyright (c) 2021, Dale Bewley; all rights reserved.
Template by Bootstrapious. Ported to Hugo by DevCows.