Getting Started with Okera
Let’s break down what you should know (or understand) about Okera under the hood. We will step through the different layers that make up your new platform for data access and governance.
If you are totally unfamiliar with Okera, you should review our overview docs first.
On this page, we will review some third-party resources you will need to be comfortable using in order to install and maintain an instance of Okera. Once you know what you’re getting into, we’ll send you to the Okera Installation page, which will provide URLs for release artifacts.
Amazon Web Services (AWS)
Presently, the Okera platform is designed to run on AWS. During the process of setting up Okera, you will configure AWS components. If your organization already uses AWS, these settings may already be known for your broader enterprise AWS environment. If you are an advanced AWS administrator, you may choose to use your preferred settings.
If you are new to AWS, we have included some links in each section below to help get you up to speed.
The full details are available in the AWS Guide
Amazon Elastic Compute Cloud (EC2)
Okera uses EC2 to provision hosts for the Okera Data Access Service (ODAS) and associated operations. Okera’s Deployment Manager allows for custom Amazon Machine Images (AMI) to be defined in case your organization prefers to use their own. We don’t mind; just be sure that is built on RHEL or CentOS Linux, version 7 or later (see Linux below).
Dependency: An AMI to base new instances on
You’ll need to be familiar with AWS IAM Roles for EC2 for authenticating access to your EC2 instances. Okera requires that your Deployment Manager (and admin systems) have a specific IAM role, and your clusters have a different, likely more locked down, IAM role. We recommend using the following roles as starters and adjusting them as necessary for your specific environment.
Dependency: IAM roles
Assuming you do not have compatible IAM roles already, create these two roles and assign them their attendant policies.
AWS Security Groups are another security mechanism in the AWS environment. These are effectively virtual firewalls that allow you to block incoming and outgoing ports between specific machines. We assume that all ports between the DM and ODAS cluster are open and recommend locking down ports with other Security Groups.
As with anything security related, you’ll want to check with your Information Security team (or equivalent) for your organization’s best practices.
Dependency: Security Group
While we recommend fine-tuning your security needs, AWS’s default security group makes a decent start.
S3 buckets are the storage backbone for ODAS. We’ll need one for installation with read and write access accessible to your DM and all the ODAS cluster instances. ODAS requires read and write access to one bucket (or prefix in the bucket) for installation and logging. For the buckets containing your data, ODAS only requires read access.
Dependency: One S3 installation bucket
The Okera platform runs on Linux. Linux commands will be provided during installation, but familiarity with these Linux commands and tools is helpful:
Okera uses Kubernetes for back-end cluster management, monitoring, and port provisioning. We’ll let Kubernetes (also sometimes written K8s) explain itself, but understanding how Kubernetes works to maintain resources and enable cluster networking will be helpful if you have to troubleshoot the system in the future. We do explain the use of Kubernetes Dashboard for monitoring Okera resources.
In conjunction with Kubernetes, we use Docker to deliver the actual ODAS executables. One way to think of it is that the Deployment Manager spins up the cluster, Kubernetes coordinates the nodes and ports, and Docker runs the services. Docker containers create an encapsulated application package that includes OS, application, and any tools required to run that application. As long as your host operating system can run the Docker application, you can run pretty much any software in a Docker container.
Docker allows us to upgrade and improve on Okera applications without requiring you to have to upgrade your infrastructure as often or as dramatically as you would if our applications ran directly on your EC2 instances. Less change means less complications. We like that.
As with Kubernetes, you will likely only have to work in the Docker layer if there is any troubleshooting required. In those cases, we’ll work with you and your team to get things back into working order.
Now that you’re oriented, the fun can begin. Our Installation document should be able to get you up and running with a suitable Deployment Manager and your first ODAS cluster.