oc describe po pod-name
oc exec pod-name cat /sys/devices/virtual/net/eth0/iflink
ip a
| --- | |
| - hosts: all | |
| become: yes | |
| become_user: jboss | |
| vars: | |
| jboss_home: /opt/jboss-eap-6.4 | |
| patch_file: jboss-eap-6.4.9-patch.zip | |
| patch_dest: /tmp | |
| patch_version: 6.4.9 |
| --- | |
| - hosts: 127.0.0.1 | |
| connection: local | |
| environment: | |
| JBOSS_MANAGEMENT_USER: ansible | |
| JBOSS_MANAGEMENT_PASSWORD: ansible | |
| JBOSS_MANAGEMENT_HOST: "10.255.0.10" | |
| JBOSS_MANAGEMENT_PORT: 9990 | |
| tasks: | |
| - name: Configure datasource |
| def missing_hours(vm_id, day) | |
| day_hours=*(0..23) | |
| present_hours = MetricRollup.where(:resource_id => vm_id, :resource_type => 'VmOrTemplate', :capture_interval_name => 'hourly').where("date_trunc('day', timestamp) = '#{day}'").group("resource_id").group("timestamp").select("timestamp").order("timestamp").collect { |rollup| rollup.timestamp.hour } | |
| day_hours - present_hours | |
| end | |
| def generate_missing(vm_id, day) | |
| objs = [] |
Tests techniques play an important role in software development, and it's no different when we are talking about Infrastructure as Code (IaC).
While developing you are always testing and constant feedback is necessary to drive your development. If you're taking to long to get feedback on a change, your steps might be too large, making errors hard to spot. Baby steps and fast feedback are the essence of TDD (Test Driven Development), but how do I apply this to the development of ad-hoc playbooks or roles?
When you're developing an automation, a typical workflow would start with a new virtual machine. We will use Vagrant to illustrate this idea, but it could be libvirt, Docker, VirtualBox or VMware used directly in your machine and even an instance in a private or public cloud or a virtual machine provisioned in your data center hypervisor (oVirt, Xen, VMware).
NOTE: When deciding which one to use you'll have to balance feedback speed and similarity with you
| --- | |
| - hosts: nodes | |
| tasks: | |
| - name: Fix bridge | |
| lineinfile: | |
| path: /etc/sysconfig/docker | |
| regexp: '^OPTIONS=' | |
| line: "OPTIONS='--selinux-enabled --log-driver=journald --bip 10.17.0.1/16'" |
| #!/bin/sh | |
| sed -i -e "/^#*[\\s]*Port\\s.*/s//Port 2222/" /etc/ssh/sshd_config | |
| semanage port -a -t ssh_port_t -p tcp 2222 | |
| systemctl restart sshd |
When you describe your technology stack, from the bottom to the top layer: hardware, OS, middleware and application - with their respective configurations - it is easy to notice that as we go up in the stack, more frequent are the changes. Your hardware will hardly change, your operating system has a long life cycle and your middleware will keep up with applications needs, the element the most changes, even if your release cycle is long (weeks or months), applications will be the volatile.
In "The Practice of System and Network Administration", the authors categorize the biggest "time sinkholes" in IT as: manual/non-standard provisioning of Operating Systems and application deployments. These time sink holes will consume your time, with either repetitive tasks or unplanned work.
| # extract private registry CA or cert to a crt file | |
| --- | |
| - hosts: all | |
| become: yes | |
| vars: | |
| private_registry_fqdn: registry.example.com | |
| tasks: |
| --- | |
| AWSTemplateFormatVersion: "2010-09-09" | |
| Description: "Template for ECS VPC in two AZ's" | |
| Parameters: | |
| VPCName: | |
| Description: The name of the VPC being created. | |
| Type: String | |
| Default: "vpc-ecs (VPC For ECS with Public and Private Subnets with a NATGW)" | |
| VPCCIDR: |