Opstella has designed to give you an entire organisation view
(could be actual organisation or team) of Application(s).
See the Organisation Lane.
These Application(s) (Platform) will have an indicator that they are under a Global Group (Organisation)
and you have to prepare the name before installation and will be use in Opstella initialisation process.
As Opstella utilizing Keycloak as its Identity and Access Management System.
It is require you to install and setup Keycloak with a dedicated Keycloak Realm for Opstella.
This is done to follow Keycloak Setup Best Practices to leave “master” realm, the default Realm from installation, for Administrative purposes only.
The Dedicated Keycloak Realm requires naming, you need to determine the name to use,
Keycloak Realm name should indicate your organisation name and relation to Opstella.
Recommended name pattern is <Company-Short-Name>-opstella
This will leave an expansion for the Keycloak for Opstella data if you decided to use this as a centralized user management for your organisation, or use the existing Keycloak.
You will be guided while installing Keycloak on how to setup but this requires your decision for naming before installation.
As you have determined the list of DevSecOps and Observability Software
but they are considered “Third-party Software” and can be deployed in many different ways.
💡 Please check out on each of tool’s documentation.
This determination affects in Infrastructure Provisioning for these deployments.
If you go with Binary Deployment, you may only need a Server to run. *
If you go with Helm Deployment, you need to have Kubernetes Cluster.
* Not counting necessary dependencies that needed.
ℹ️ Some of the tools/instruments may exclusively run and only on Kubernetes Cluster.
Ultimately, the target goal is to have a collective of DevSecOps and Observability Tools up an running, exposed service with network, accessible by Opstella, to complete the platform.
💡 As a recommendation from Opstella, we recommend you to follow Reference Architecture.
Part 2: Determine Kubernetes Cluster(s) that will deploy Opstella-managed Application Workload
Your application will be managed with Opstella and deployed on an infrastructure that integrated with Opstella,
once your application has gone through onboarding process.
The ONLY infrastructure that Opstella support is Kubernetes.
💡 You need to have Kubernetes Cluster(s) setup and ready to use.
Often that Your Application(s) will have separated instances for different purposes in DevSecOps cycle,
and allow for separation of different processes such as various testing or staging your application.
This is depends on your requirements and meaning of managing applications but Opstella by default, will embrace the separation.
It is also a good practice that for the application separation, should also separate the underlying infrastructure
that running the application as well.
Applications managed by Opstella will be separated by Kubernetes Namespace with Environment suffix on Namespace naming.
This opens for flexibility that may constrained by your infrastructure limitation.
For instance, From 5 Environments you can have one of the following example scenarios.
Scenario #1 - Entirely Consolidated
Utilized 1 Kubernetes Cluster
Kubernetes #1 (Consolidated)
🟦 DEV🟨 SIT🟪 UAT⬜ PRE🟥 PRD
Scenario #2 - Separate by Group (Non-Production/Production)
Utilized 2 Kubernetes Clusters
Kubernetes #1 (Non-Production)
Kubernetes #2 (Production)
🟦 DEV🟨 SIT🟪 UAT
⬜ PRE🟥 PRD
Scenario #3 - Entirely Dedicated
Utilized 5 Kubernetes Clusters
Kubernetes #1
Kubernetes #2
Kubernetes #3
Kubernetes #4
Kubernetes #5
🟦 DEV
🟨 SIT
🟪 UAT
⬜ PRE
🟥 PRD
Please have this strategy determined and you will know how would you provision Kubernetes Cluster(s) for Application Workload
follow to your Environment(s) designation and match to your infrastructure constrains.
💡 It is recommended to use Reference Architecture as a starting point to plan your infrastructure.
All Machines are provisioned within the number of instances required, supported Operating System, Compute Specifications, ready to use, and ready to install the corresponding software and its dependencies.
Usually Kubernetes Cluster(s) are multiple Server Machines.
Either Physical or Virtualization.
Kubernetes Cluster(s) should be provisioned within the supported Version, Specifications.
All Machines for Kubernetes Cluster(s) are provisioned within the number of instances required, supported Operating System, Compute Specifications, ready to use, and ready to install the corresponding software and its dependencies.
Opstella and some of components/tools requires an S3-compatible Object Storage Service.
You need to determine whether to host your own S3-Compatible Object Storage Service or Bring your own Service.
S3 is a RESTful API standard used for interacting with object storage
and de facto industry standard for cloud-based data storage, used by countless application.
Network Policies (Firewall) are either unrestricted or fully satisfied on all underlying infrastructure (Machines/Machines for Kubernetes Clusters) and any cross-connection with its needs for servicing.
If Firewall is required to be configured properly,
It must satisfied on all Virtual Machines, with its needs for servicing
It must satisfied on all Control Plane/Worker Nodes for Kubernetes, with its needs for servicing
Outbound Connection is preferred Open to Internet without Proxies or Highly Restricted Firewall
