Blog & Insights

curl https://releases.rancher.com/install-docker/19.03.sh | sh

mkdir /opt/rancher

docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /opt/rancher:/var/lib/rancher rancher/rancher:latest

https://raw.githubusercontent.com/keyvatech/blog_files/master/centos7_cloudinit_vmtemplate.sh

This guide will walk through how to set up Red Hat Ansible Tower in a highly-available configuration. In this example, we will set up 4 different systems – 1 for PostgreSQL database (towerdb), and 3 web nodes for Tower (tower1, tower2, tower3). 

We will be using Ansible Tower v3.6 and PostgreSQL 10, on RHEL 7 systems running in VMware for this technical guide. The commands for setting up the same configuration on RHEL 8 will be different for some cases.  This guide does not account for clustering of the PostgreSQL database. If you are setting up Tower in HA capacity for Production environments, it is recommended to follow best practices for PostgreSQL clustering, to avoid a single point of failure. 

First, we will need to prep all the RHEL instances by enabling the Red Hat repos. All the commands below are to be run on all 4 systems – towerdb, tower1, tower2, tower3 

subscription-manager register 

subscription-manager refresh 

subscription-manager attach –-auto 

subscription-manager repos –-list  

subscription-manager repos --enable rhel-7-server-rh-common-beta-rpms 

subscription-manager repos --enable rhel-7-server-rpms 

subscription-manager repos --enable rhel-7-server-source-rpms 

subscription-manager repos --enable rhel-7-server-rh-common-source-rpms 

subscription-manager repos --enable rhel-7-server-rh-common-debug-rpms 

subscription-manager repos --enable rhel-7-server-optional-source-rpms 

subscription-manager repos --enable rhel-7-server-extras-rpms 

sudo yum update 

sudo yum install wget 

sudo yum install python36 

sudo pip3 install httpie 

Also: 

1. a) Update the /etc/hosts file on all 4 hosts with entries for all systems
2. b) Add and copy thesshkeys on all systems 

On the Database system (towerdb), we will now set up PostgreSQL 10 

sudo yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm 

sudo yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm 

sudo yum install postgresql10 postgresql10-server 

Initialize the database 

/usr/pgsql-10/bin/postgresql-10-setup initdb 

systemctl enable postgresql-10 

systemctl start postgresql-10 

Verify you can log in to the database 

:~
nbsp;sudo su – postgres 
:~
nbsp;Psql  
# \list 
This command will show you the existing (default) database list. 
Next, we will configure the database to make sure it can talk to all the Tower web nodes: 
sudo vi /var/lib/pgsql/10/data/pg_hba.conf 

Add/update the line with 'md5' entry to allow all hosts:  
host    all             all             0.0.0.0/0            md5 
Update the postgresql.conf file 
sudo vi /var/lib/pgsql/10/data/postgresql.conf

Add/update the entry to listen to all incoming requests:  
listen_addresses = '*' 

Restart the database services, to pick up the changes made: 
sudo systemctl restart postgresql-10 

sudo systemctl status postgresql-10 
 
On each of the Tower web nodes (tower1, tower2, tower3), we will set up the Ansible Tower binaries: 
mkdir ansible-tower 

cd ansible-tower/ 

wget https://releases.ansible.com/ansible-tower/setup-bundle/ansible-tower-setup-bundle-3.6.2-1.el7.tar.gz 

tar xvzf ansible-tower-setup-bundle-3.6.2-1.el7.tar.gz  

cd ansible-tower-setup-bundle-3.6.2-1 

python -c 'from hashlib import md5; print("md5" + md5("password" + "awx").hexdigest())' 

md5f58b4d5d85dbde46651335d78bb56b8c 
Where password will be the password that you will be using a hash of, when authenticating against the database 
Back on the database server (towerdb), we will go ahead and set up the database schema pre-requisites for Tower install:  
:~
nbsp;sudo su – postgres 
:~
nbsp;Psql  
postgres=# CREATE USER awx; CREATE DATABASE awx OWNER awx; ALTER USER awx WITH password 'password'; 
On tower1, tower2, tower3, update the inventory file and run the setup. Make sure your script contents match on all tower web tier systems. 
You will need to update at least the following values and customize them for your environment: 
admin_password='password' 

pg_password='password' 

rabbit_mq = 'password' 
Under the [tower] section, you will have to add entries for all your tower web hosts. The first entry will typically serve as the primary node when the cluster is run.  
We will now run the setup script: 
./setup.sh 
You can either copy this inventory file on the other 2 tower systems (tower2 and tower3), or replicate the content to match the content in the file on tower1, and run the setup script on the other 2 tower systems as well.  
Once the setup script is run on all hosts, and it finishes successfully, you will be able to test your cluster instance. You can do so by going to one of the tower hosts URL, initiating a job template, and see which specific tower node it runs on – based on the tower node that is designated to be the primary node at that time. You will also be able to view the same console details, and logs of job runs, regardless of which tower web URL you go to.  
If you have any questions or comments on the tutorial content above, or run in to specific errors not covered here, please feel free to reach out to [email protected].

By Anuj Tuli, Chief Technology Officer

Typically when you hear about containers and Kubernetes, it is in the context of Linux or Unix platforms. But there are a large number of organizations that use Windows and .NET based applications, and they are still trying to determine the best way forward for containerization of their Windows based business critical applications.  

Kubernetes added support for Windows based components (worker nodes) starting with release v1.14.  

In the example below, we will join a Windows worker node (v1.16.x) with a Kubernetes cluster v1.17.x. 

As of this moment, Windows worker nodes are supported on Windows 2019 operating system only. In this example, we will leverage the flannel network set up on our master node on RHEL (see instructions above).  

Step 1: Download the sig-windows-tools repository from https://github.com/kubernetes-sigs/sig-windows-tools , and extract the files 

Step 2: Navigate to, and update the Kubernetes configuration file at C:\<Download-Path>\kubernetes\kubeadm\v1.16.0\Kubeclustervxlan 

In our instance, we will update the following values: 

• Interface Name 
• Control Plane details – IP address, username, KubeadmToken, KubeadmCAHash. The values for these come from the output of the kubectl join command, when it was run during set up of the master node

Step 3: Open up PowerShell console in Admin mode and install kubernetes via the downloaded script. This step requires reboot of the server 

PS C:\Users\Administrator> cd C:\<Download-Path>\kubernetes\kubeadm 

PS C:\<Download-Path>\kubernetes\kubeadm> .\KubeCluster.ps1 -ConfigFile C:\<Download-Path>\kubernetes\kubeadm\v1.16.0\Kubeclustervxlan.json -install 

Step 4: Once K8s is installed, join it to the existing kubernetes cluster. This step takes the values you entered in the modified Kubeclustervxlan file 

PS C:\<Download-Path>\kubernetes\kubeadm> .\KubeCluster.ps1 -ConfigFile C:\<Download-Path>\kubernetes\kubeadm\v1.16.0\Kubeclustervxlan.json -join 

Step 5: Verify that the Windows worker node was successfully added to the cluster. You can do this by running the kubectl command from any client (Windows or Linux nodes on the cluster)  

PS C:\<Download-Path>\kubernetes\kubeadm> kubectl get nodes 

NAME                    STATUS   ROLES    AGE   VERSION 
kubemaster.bpic.local   Ready    master   15h   v1.17.3 
kubenode1.bpic.local    Ready    <none>   14h   v1.17.3 
kubenode2.bpic.local    Ready    <none>   14h   v1.17.3 
win-eo5rgh4493r         Ready    <none>   12h   v1.16.2 

If you have any questions or comments on the tutorial content above, or run in to specific errors not covered here, please feel free to reach out to [email protected] 

By Anuj Tuli, CTO

Keyva announces the certification of their ServiceNow App for Red Hat Ansible Tower against the Orlando release (latest release) of ServiceNow. ServiceNow announced its release of Orlando on January 23rd, 2020, which is the newest version in the long line of software updates since the company's creation.  

Customers can now upgrade their ServiceNow App for Ansible Tower from previous ServiceNow Releases – London, Madrid, New York – to Orlando release seamlessly. 

You can find out more about the App, and view all the ServiceNow releases it is certified against, on the ServiceNow store here: http://bit.ly/2W5tYHv

By Brad Johnson, Lead DevOps Engineer

When developing automation you may be faced with challenges that are simply too complicated or tedious to accomplish with Ansible alone. There may even be cases where you are told that “it can’t be automated”. However, when you combine the abilities of Ansible and custom python using the pexpect  module, then you are able to automate practically anything you can do on the command line. In this post we will discuss the basics of creating a custom Ansible module in python.  

Here are a few examples of cases where you might need to create a custom module: 

• Running command line programs that drop into a new shell or interactive interface. 
• Processing complex data and returning a subset of specific data in a new format. 
• Interacting with a database and returning data in a specific format for further Ansible processing.
  

For the purposes of this article we will focus on the first case. When writing a traditional linux shell or bash script it simply isn’t possibly to continue your script when a command you run drops you into a new shell or new interactive interface. If these tools also provided a non-interactive mode or config/script input we would not need to do this. To overcome this situation we need to use python with pexpect. The native Ansible “expect” module provides a simple interface to this functionality and should be evaluated before writing a custom module. However, when you need more complex interactions, want specific data returned or want to provide a re-usable and simpler interface to an underlying program for to others to consume, then custom development if warranted.  

In this guide I will talk about the requirements and steps needed to create your own library module. The source code with our example is located here and contains notes in the code as well. The pexpect code is intentionally complex to demonstrate some use cases.

Module Code (Python)

#!/usr/bin/env python
import os
import getpass

DOCUMENTATION = '''
---
module: my_module

short_description: This is a custom module using pexpect to run commands in myscript.sh

description:
    - "This module runs commands inside a script in a shell. When run without commands it returns current settings only."

options:
    commands:
        description:
            - The commands to run inside myscript in order
        required: false
    options:
        description:
            - options to pass the script
        required: false
    timeout:
        description:
            - Timeout for finding the success string or running the program
        required: false
        default: 300
    password:
        description:
            - Password needed to run myscript
        required: true

author:
    - Brad Johnson - Keyva
'''

EXAMPLES = '''
- name: "Run myscript to set up myprogram"
  my_module:
    options: "-o myoption"
    password: "{{ myscript_password }}"
    commands:
      - "set minheap 1024m"
      - "set maxheap 5120m"
      - "set port 7000"
      - "set webport 80"
    timeout: 300
'''

RETURN = '''
current_settings: String containing current settings after last command was run and settings saved
    type: str
    returned: On success
logfile: String containing logfile location on the remote host from our script
    type: str
    returned: On success
'''


def main():
    # This is the import required to make this code an Ansible module
    from ansible.module_utils.basic import AnsibleModule
    # This instantiates the module class and provides Ansible with
    # input argument information, it also enforces input types
    module = AnsibleModule(
        argument_spec=dict(
            commands=dict(required=False, type='list', default=[]),
            options=dict(required=False, type='str', default=""),
            password=dict(required=True, type='str', no_log=True),
            timeout=dict(required=False, type='int', default='300')
        )
    )
    commands = module.params['commands']
    options = module.params['options']
    password = module.params['password']
    timeout = module.params['timeout']

    try:
        # Importing the modules here allows us to catch them not being installed on remote hosts
        #   and pass back a failure via ansible instead of a stack trace.
        import pexpect
    except ImportError:
        module.fail_json(msg="You must have the pexpect python module installed to use this Ansible module.")

    try:
        # Run our pexpect function
        current_settings, changed, logfile = run_pexpect(commands, options, password, timeout)
        # Exit on success and pass back objects to ansible, which are available as registered vars
        module.exit_json(changed=changed, current_settings=current_settings, logfile=logfile)
    # Use python exception handling to keep all our failure handling in our main function
    except pexpect.TIMEOUT as err:
        module.fail_json(msg="pexpect.TIMEOUT: Unexpected timeout waiting for prompt or command: {0}".format(err))
    except pexpect.EOF as err:
        module.fail_json(msg="pexpect.EOF: Unexpected program termination: {0}".format(err))
    except pexpect.exceptions.ExceptionPexpect as err:
        # This catches any pexpect exceptions that are not EOF or TIMEOUT
        # This is the base exception class
        module.fail_json(msg="pexpect.exceptions.{0}: {1}".format(type(err).__name__, err))
    except RuntimeError as err:
        module.fail_json(msg="{0}".format(err))


def run_pexpect(commands, options, password, timeout=300):
    import pexpect
    changed = True
    script_path = '/path/to/myscript.sh'
    if not os.path.exists(script_path):
        raise RuntimeError("Error: the script '{0}' does not exist!".format(script_path))
    if script_path == '/path/to/myscript.sh':
        raise RuntimeError("This module example is based on a hypothetical command line interactive program and "
                           "can not run. Please use this as a basis for your own development and testing.")
    # Set prompt to expect with username embedded in it
    # YOU MAY NEED TO CHANGE THIS PROMPT FOR YOUR SYSTEM
    # My default RHEL prompt regex
    prompt = r'\[{0}\@.+?\]\$'.format(getpass.getuser())
    output = ""

    child = pexpect.spawn('/bin/bash')
    try:
        # Look for initial bash prompt
        child.expect(prompt)
        # Start our program
        child.sendline("{0} {1}".format(script_path, options))
        # look for our scripts logfile prompt
        # Example text seen in output: 'Logfile: /path/to/mylog.log'
        child.expect(r'Logfile\:.+?/.+?\.log')
        # Note that child.after contains the text of the matching regex
        logfile = child.after.split()[1]
        # Look for password prompt
        i = child.expect([r"Enter password\:", '>'])
        if i == 0:
            # Send password
            child.sendline(password)
            child.expect('>')
        # Increase timeout for longer running interactions after quick initial ones
        child.timeout = timeout
        try:
            # Look for program internal prompt or new config dialog
            i = child.expect([r'Initialize New Config\?', '>'])
            # pexpect will return the index of the regex it found first
            if i == 0:
                # Answer 'y' to initialize new config prompt
                child.sendline('y')
                child.expect('>')
            # If any commands were passed in loop over them and run them one by one.
            for command in commands:
                child.sendline(command)
                i = child.expect([r'ERROR.+?does not exist', r'ERROR.+?$', '>'])
                if i == 0:
                    # Attempt to intelligently add items that may have multiple instances and are missing
                    # e.g. "socket.2" may need "add socket" run before it.
                    # Try to allow the user just to use the set command and run add as needed
                    try:
                        new_item = child.after.split('"')[1].split('.')[0]
                    except IndexError:
                        raise RuntimeError("ERROR: unable to automatically add new item in myscript,"
                                           " file a bug\n  {0}".format(child.after))
                    child.sendline('add {0}'.format(new_item))
                    i = child.expect([r'ERROR.+?$', '>'])
                    if i == 0:
                        raise RuntimeError("ERROR: unable to automatically add new item in myscript,"
                                           " file a bug\n  {0}".format(child.after.strip()))
                    # Retry the failed original command after the add
                    child.sendline(command)
                    i = child.expect([r'ERROR.+?$', '>'])
                    if i == 0:
                        raise RuntimeError("ERROR: unable to automatically add new item in myscript,"
                                           " file a bug\n  {0}".format(child.after.strip()))
                elif i == 1:
                    raise RuntimeError("ERROR: unspecified error running a myscript command\n"
                                       "  {0}".format(child.after.strip()))
            # Set timeout shorter for final commands
            child.timeout = 15
            # If we processed any commands run the save function last
            if commands:
                child.sendline('save')
                # Using true loops with expect statements allow us to process multiple items in a block until
                #    some kind of done or exit condition is met where we then call a break.
                while True:
                    i = child.expect([r'No changes made', r'ERROR.+?$', '>'])
                    if i == 0:
                        changed = False
                    elif i == 1:
                        raise RuntimeError("ERROR: unexpected error saving configuration\n"
                                           "  {0}".format(child.after.strip()))
                    elif i == 2:
                        break
            # Always print out the config data from out script and return it to the user
            child.sendline('print config')
            child.expect('>')
            # Note that child.before contains the output from the last expected item and this expect
            current_settings = child.before.strip()
            # Run the 'exit' command that is inside myscript
            child.sendline('exit')
            # Look for a linux prompt to see if we quit
            child.expect(prompt)
        except pexpect.TIMEOUT:
            raise RuntimeError("ERROR: timed out waiting for a prompt in myscript")
        # Get shell/bash return code of myscript
        child.sendline("echo $?")
        child.expect(prompt)
        # process the output into a variable and remove any whitespace
        exit_status = child.before.split('\r\n')[1].strip()
        if exit_status != "0":
            raise RuntimeError("ERROR: The command returned a non-zero exit code! '{0}'\n"
                               "Additional info:\n{1}".format(exit_status, output))
        child.sendline('exit 0')
        # run exit as many times as needed to exit the shell or subshells
        # This might be useful if you ran a script that put you into a new shell where you then ran some other scripts
        # This is also a good example of
        while True:
            i = child.expect([prompt, pexpect.EOF])
            if i == 0:
                child.sendline('exit 0')
            elif i == 1:
                break
    finally:
        # Always try to close the pexpect process
        child.close()
    return current_settings, changed, logfile


if __name__ == '__main__':
    main()

In order to create a module you need to put your new “mymodule.py” file somewhere in the Ansible module library path, typically the “library” directory next to your playbook or library inside your role. It’s also important to note that Ansible library modules run on the target ansible host, so if you want to use the ansible “expect” module or make a custom module with pexpect in it then you will need to install the python pexpect module on the remote host before running module. (Note: the pexpect version provided in RHEL/CentOS repos is old and will not support the Ansible “expect” module, install via pip instead for the latest version.) 

 Information on the library path is located here: 

https://docs.ansible.com/ansible/latest/dev_guide/developing_locally.html 

 Your example.py file needs to be a standard file with a python shebang header and also import the ansible module. Here is a bare minimum amount of code needed for an ansible module. 

#!/usr/bin/env python 
from ansible.module_utils.basic import AnsibleModule 
module = AnsibleModule(argument_spec=dict(mysetting=dict(required=False, type='str'))) 
try: 
    return_value = "mysetting value is: {0}".format(module.params['mysetting']) 
except: 
    module.fail_json(msg="Unable to process input variable into string") 
module.exit_json(changed=True, my_output=return_value) 

With this example you can see how variables are passed into and out of the module. This also includes a basic exception handle for dealing with errors and allowing ansible to deal with the failure. This exception clause is too broad for normal use as it will catch and hide all errors that could happen in the try block. When you create your module you should only except error types that you anticipate to avoid hiding stack traces of unexpected errors from your logs. 

Now we can add in some custom pexpect processing code. This is again a very basic example. The example code linked in this blog post has a complicated and in-depth example. This function would then be added into our try-except block in the code above. 

def run_pexpect(password): 
    import pexpect 
    child = pexpect.spawn('/path/to/myscript.sh') 
    child.timeout = 60 
    child.expect(r"Enter password\:") 
    child.sendline(password) 
    child.expect('Thank you') 
    child.sendline('exit') 
    child.expect(pexpect.EOF) 
    exit_dialog = child.before.strip() 

    return exit_dialog

There are some important things to note here when dealing with pexpect and Ansible. 

• If the program hits a timeout it will raise “pexpect.TIMEOUT” and if it terminates unexpectedly it will raise “pexpect.EOF”. These exceptions will need to be either expected, with child.expect or excepted using pythons exception handling. Any other exceptions don’t really need to be handled as then are likely real errors that should cause failure and raise a stack trace.  
• Always use a timeout! Be careful never to set the timeout to None as an unattended process will hang forever waiting on any new/unexpected prompt. It’s always better to set a very generous timeout over none at all. You can change the timeout multiple times in code based on how long you expect each prompt to take to come back. 
• If you do not set a timeout value at all the default for the spawn class is 30 seconds. This is the timeout looking for the text in an expect method. Even if your program is outputting text to stdout, when the timeout is hit before the string is found then the program is killed and pexpect.TIMEOUT is raised. 

• Don’t use print functions in python to try to send information back to Ansible. Printing to stdout with your module will cause ansible to register a failure. All output and information should be passed back through an Ansible method like “module.exit_json”.  
• For debugging you may want to use the “child.logfile” facility to create log files on the remote system. 
• The “child.expect” method takes regular expressions as input. If you want an explicit string you can always “import re” and use the “re.escape” method on a string to escape it. 

When creating custom modules I would encourage you to give thought to making the simplest, most maintainable and modular modules possible. It can be easy to create one module/script to rule them all, but the linux concept of having one tool to do one thing well will save you rewriting chunks of code that do the same thing and also help future maintainers of the automation you create. 

Helpful links: 

https://docs.ansible.com/ansible/latest/modules/expect_module.html 

https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html 

https://pexpect.readthedocs.io/en/stable/overview.html 

If you have any questions about the steps documented here, would like more information on the custom development process, or have any feedback or requests, please let us know at [email protected].

Kong Enterprise provides you the ability to rate limit the traffic for various objects using the Rate Limiting Advanced Plugin. In the example below, we will rate limit a service fronted by Kong Enterprise.  

We will use our existing Kong Enterprise on RHEL 7 environment. The installation process for this environment is documented here.

First lets make sure we have an existing service we can use. If your environment needs to have a service created, you can also check out our blog on how to do so here.

We will also be using the RBAC controls and the user we set up in our blog post. If you have not yet setup RBAC you can learn how to do so here.

1) Create a service that we can use for this example 

Log in to the Kong portal at https://<kong_FQDN_or_IP>:8445 and navigate to your chosen Workspace -> Services -> New Service 

Fill in the fields for Service Name, Host, Path, Port and other fields as necessary 

You can also run the step of creating a Service via the command line in the format below: 

curl -i -X POST --url http://<kong_FQDN_or_IP>:8001/services --data 'name=DemoService' --data 'url=myurl.com' 

Check to make sure the Service was created successfully by navigating through the console 

Or running the following command line: 

curl -i -X GET --url "http://<kong_FQDN_or_IP>:8001/services" --header "Kong-Admin-Token: rbac_user_token_1" 

2) Next we will add a route for this service 

curl -i -X POST --url "http://<kong_FQDN_or_IP>:8001/services/DemoService/routes" --data "hosts[]=mydemoexample.com" --header "Kong-Admin-Token: rbac_user_token_1" 

3) Use the rate limiting plugin with our defined service 

curl -i -X POST --url "http://<kong_FQDN_or_IP>:8001/services/DemoService/plugins" --data "name=rate-limiting-advanced" --data "config.sync_rate=0" --data "config.window_size=60" --data "config.limit=2" --header "Kong-Admin-Token: rbac_user_token_1"  

This configuration means that the DemoService service should not be allowed to process more than 2 requests per 60 seconds period.  

4) Now we will test running more than 2 requests against the DemoService service.  

After running the request below more than twice 

curl -i -X GET --url "http://<kong_FQDN_or_IP>:8000/" --header "Host: mydemoexample.com" --header "Kong-Admin-Token: rbac_user_token_1" 

We get the following message:  

HTTP/1.1 429 Too Many Requests 

By controlling the volume of requests to a specific service, and by adding RBAC controls in front of it, you can secure a quasi-firewall for east-west traffic against internal networking vulnerabilities.   

If you have any questions or comments on the tutorial content above, or run in to specific errors not covered here, please feel free to reach out to [email protected] 

If you've used the community version of the Kong API gateway, you have probably noticed that anyone that knows the server name or IP for your Kong community API gateway can access and modify existing objects including services and routes. To set up and use role-based access control Kong Enterprise version provides additional capabilities.  

In this example, we will leverage the Kong Enterprise on RHEL 7 lab instance we set up earlier. You can read the install steps here.

Before getting started, please make sure enforce_rbac=on is in the kong.conf file.

Log in to https://<Kong-Enterprise-VM-IP>:8445/login using kong_admin as the username and the password you set during the install process (this is the same password you assigned during the step of EXPORT_PASSWORD='password') 

Click on Teams -> RBAC Users  

Create a new user rbac_user_1 with a token of rbac_user_token_1  

Make sure that enabled checkbox is checked 

Add roles –> admin  

Note that we are creating this user with 'admin' permissions, but not 'super-admin'. So it will have access to all endpoints, across all workspaces—except RBAC Admin API. 

A new RBAC user, rbac_user_1, gets created 

Now let's try and test the RBAC setup. We will use Postman (https://www.getpostman.com/) for this example.  

First we will create a new Collection labeled 'Kong Enterprise' and then a new Request within that Collection called 'Get Services'. 

Next, we will try to run a GET request against https://<Kong-Enterprise-VM-IP>:8445/services to list out all available services. If you don't pass any headers or credentials, you get the error notification "Invalid credentials. Token or User credentials required". 

By adding the header with Kong-Admin-Token and the value of the token set in the earlier step 'rbac_user_token_1', we try to run the request again and this time it succeeds 

As you can see, with RBAC enabled, Kong Enterprise provides much greater control over who can access and modify various objects. The user permissions can be tailored to suit various team needs – depending upon how granular you want access to be.  

If you have any questions or comments on the tutorial content above, or run in to specific errors not covered here, please feel free to reach out to [email protected] 

We all know that Agile is has been around for a while now. You have probably heard about it a thousand times already over the past few years. But even today there are organizations (e.g. Utilities – that prefer CapEx) that rely heavily on the waterfall model for software development – whereby all the project and implementations details are agreed to by the stakeholders upfront. In the past, this practice has proved to be risky, inflexible, too time consuming and costly at the beginning of the project. When starting any new project, even when applying all possible game theory outcomes to determine the risk and estimated effort, at some point you don’t know what you don't know. The methodology of Agile helps alleviate some of these issues. Using various methodologies, the process of Agile allows for the requirements to evolve and change, and a team comprised of developers and experts from various organizational areas work together to address the tasks as they evolve. This type of a setup is typically led by a Scrum Master that leads regular checkpoint meetings with the stakeholders, helps break down the work into smaller chunks to be picked up by the developers, and sets up timelines for completion and accountability.  

There are several methodologies and frameworks that you can follow to be more Agile -  for example, you can use Scrum methodology, Test-Driven Development, DevOps, Continuous Integration, Continuous Delivery, Kanban, Extreme Programming, and more. The idea is to be able to provide flexibility and avoiding lock-in to a set process or tools, and have regular checkpoints with the stakeholders so that any shifts in directly can be accommodated earlier in the cycle. 

The Manifesto for Agile Software Development outlines the following four values: 

• Individuals and Interactions over processes and tools  
• Working Software over comprehensive documentation  
• Customer Collaboration over contract negotiation  
• Responding to Change over following a plan  

It also follows the following twelve principles: 

1. Customer satisfaction by early and continuous delivery of valuable software. 
2. Welcome changing requirements, even in late development. 
3. Deliver working software frequently (weeks rather than months) 
4. Close, daily cooperation between business people and developers 
5. Projects are built around motivated individuals, who should be trusted 
6. Face-to-face conversation is the best form of communication (co-location) 
7. Working software is the primary measure of progress 
8. Sustainable development, able to maintain a constant pace 
9. Continuous attention to technical excellence and good design 
10. Simplicity—the art of maximizing the amount of work not done—is essential 
11. Best architectures, requirements, and designs emerge from self-organizing teams 
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly 

The Product Owner is one of the most important stakeholders in the Agile process. Product Owner is responsible for setting the overall strategy and direction for the deliverable that is being worked. It is quite easy to miss the big picture of what is being delivered and why, because the Scrum tasks are at a very low level. The Product Owner's role is to help make sense of all the small unrelated tasks, to deliver a product that provides business value to the organization.   

Keyva has offerings available to help you with your Agile journey. You can find more information here. Please contact us if you'd like to have us review your environment and provide suggestions on what might work for you. Simply drop us a line here: [email protected]  

curl https://releases.rancher.com/install-docker/19.03.sh | sh

mkdir /opt/rancher

docker run -d --restart=unless-stopped -p 80:80 -p 443:443 -v /opt/rancher:/var/lib/rancher rancher/rancher:latest

https://raw.githubusercontent.com/keyvatech/blog_files/master/centos7_cloudinit_vmtemplate.sh