From c5546fba8228414f00da879f33cbb536f8ce628c Mon Sep 17 00:00:00 2001 From: redkubesbot Date: Wed, 24 Jan 2024 08:05:22 +0000 Subject: [PATCH] deploy: 5b9bfa1fbeac5d2f41fc2e859fc0cfaed8f90517 --- 404.html | 4 ++-- assets/js/{042c512d.6637f92d.js => 042c512d.81b69616.js} | 2 +- assets/js/{21fbcd7c.2be8af33.js => 21fbcd7c.1b4c4acb.js} | 2 +- assets/js/{2d9c895d.b7386f49.js => 2d9c895d.cfb99443.js} | 2 +- assets/js/{3d235714.ed09bcde.js => 3d235714.dab34a6e.js} | 2 +- assets/js/{4f01d7c7.83164f21.js => 4f01d7c7.f12f572f.js} | 2 +- assets/js/{5db37859.9f73e243.js => 5db37859.9b4fc439.js} | 2 +- assets/js/{70b0dc77.fde1e8cb.js => 70b0dc77.869b8552.js} | 2 +- assets/js/{73148982.041cb4ba.js => 73148982.8d276d5c.js} | 2 +- assets/js/{8f69df39.129b4e23.js => 8f69df39.935e1adc.js} | 2 +- assets/js/{b0500dc6.f5f3cc95.js => b0500dc6.81ecb920.js} | 2 +- assets/js/{b4b7b186.4ab79471.js => b4b7b186.0e2a4edc.js} | 2 +- assets/js/{c1cd9779.f2b1173b.js => c1cd9779.f594a6c7.js} | 2 +- assets/js/{c642c7e8.2136c116.js => c642c7e8.142d5454.js} | 2 +- assets/js/{d673e682.87a4a0f3.js => d673e682.47198934.js} | 2 +- assets/js/{e878c199.d13050b3.js => e878c199.93aca584.js} | 2 +- assets/js/{efe7c983.9241def9.js => efe7c983.20929ee8.js} | 2 +- assets/js/{f1abdd8c.ed966a4c.js => f1abdd8c.5cf402fb.js} | 2 +- .../{runtime~main.110a1fa6.js => runtime~main.f463275f.js} | 2 +- community/code-of-conduct/index.html | 6 +++--- community/community-values/index.html | 6 +++--- community/expectations/index.html | 6 +++--- community/welcome/index.html | 6 +++--- docs/apps/alertmanager/index.html | 4 ++-- docs/apps/argocd/index.html | 4 ++-- docs/apps/certmanager/index.html | 4 ++-- docs/apps/cloudnativepg/index.html | 4 ++-- docs/apps/drone/index.html | 4 ++-- docs/apps/external-dns/index.html | 4 ++-- docs/apps/falco/index.html | 4 ++-- docs/apps/gatekeeper/index.html | 4 ++-- docs/apps/gitea/index.html | 4 ++-- docs/apps/grafana/index.html | 4 ++-- docs/apps/harbor/index.html | 4 ++-- docs/apps/ingress-nginx/index.html | 4 ++-- docs/apps/istio/index.html | 4 ++-- docs/apps/jaeger/index.html | 4 ++-- docs/apps/keycloak/index.html | 4 ++-- docs/apps/kiali/index.html | 4 ++-- docs/apps/knative/index.html | 4 ++-- docs/apps/loki/index.html | 4 ++-- docs/apps/minio/index.html | 4 ++-- docs/apps/otel/index.html | 4 ++-- docs/apps/prometheus/index.html | 4 ++-- docs/apps/tekton/index.html | 4 ++-- docs/apps/thanos/index.html | 4 ++-- docs/apps/trivy/index.html | 4 ++-- docs/apps/vault/index.html | 4 ++-- docs/apps/velero/index.html | 4 ++-- docs/for-ciso/overview/index.html | 4 ++-- docs/for-devs/console/apps/index.html | 4 ++-- docs/for-devs/console/builds/index.html | 4 ++-- docs/for-devs/console/catalog/index.html | 4 ++-- docs/for-devs/console/dashboard/index.html | 4 ++-- docs/for-devs/console/deploy-changes/index.html | 4 ++-- docs/for-devs/console/projects/index.html | 4 ++-- docs/for-devs/console/secrets/index.html | 4 ++-- docs/for-devs/console/services/index.html | 4 ++-- docs/for-devs/console/settings/index.html | 4 ++-- docs/for-devs/console/shell/index.html | 4 ++-- docs/for-devs/console/shortcuts/index.html | 4 ++-- docs/for-devs/console/workloads/index.html | 4 ++-- docs/for-ops/cli/apply/index.html | 4 ++-- docs/for-ops/cli/bash/index.html | 4 ++-- docs/for-ops/cli/bootstrap/index.html | 4 ++-- docs/for-ops/cli/check-policies/index.html | 4 ++-- docs/for-ops/cli/commit/index.html | 4 ++-- docs/for-ops/cli/decrypt/index.html | 4 ++-- docs/for-ops/cli/deploying/index.html | 4 ++-- docs/for-ops/cli/destroy/index.html | 4 ++-- docs/for-ops/cli/diff/index.html | 4 ++-- docs/for-ops/cli/encrypt/index.html | 4 ++-- docs/for-ops/cli/installation/index.html | 4 ++-- docs/for-ops/cli/known-issues/index.html | 4 ++-- docs/for-ops/cli/lint/index.html | 4 ++-- docs/for-ops/cli/pull/index.html | 4 ++-- docs/for-ops/cli/rotate-keys/index.html | 4 ++-- docs/for-ops/cli/status/index.html | 4 ++-- docs/for-ops/cli/sync/index.html | 4 ++-- docs/for-ops/cli/template/index.html | 4 ++-- docs/for-ops/cli/test/index.html | 4 ++-- docs/for-ops/cli/validate-templates/index.html | 4 ++-- docs/for-ops/cli/validate-values/index.html | 4 ++-- docs/for-ops/cli/values/index.html | 4 ++-- docs/for-ops/cli/x/index.html | 4 ++-- docs/for-ops/console/apps/index.html | 4 ++-- docs/for-ops/console/backups/index.html | 4 ++-- docs/for-ops/console/builds/index.html | 4 ++-- docs/for-ops/console/clusters/index.html | 4 ++-- docs/for-ops/console/dashboard/index.html | 4 ++-- docs/for-ops/console/deploy-changes/index.html | 4 ++-- docs/for-ops/console/overview/index.html | 4 ++-- docs/for-ops/console/policies/index.html | 4 ++-- docs/for-ops/console/projects/index.html | 4 ++-- docs/for-ops/console/secrets/index.html | 4 ++-- docs/for-ops/console/services/index.html | 4 ++-- docs/for-ops/console/settings/alerts/index.html | 4 ++-- docs/for-ops/console/settings/azure/index.html | 4 ++-- docs/for-ops/console/settings/backup/index.html | 4 ++-- docs/for-ops/console/settings/cluster/index.html | 4 ++-- docs/for-ops/console/settings/co-monitoring/index.html | 4 ++-- docs/for-ops/console/settings/dns/index.html | 4 ++-- docs/for-ops/console/settings/ingress/index.html | 4 ++-- docs/for-ops/console/settings/key-management/index.html | 4 ++-- docs/for-ops/console/settings/oidc/index.html | 4 ++-- docs/for-ops/console/settings/otomi/index.html | 4 ++-- docs/for-ops/console/settings/smtp/index.html | 4 ++-- docs/for-ops/console/shell/index.html | 4 ++-- docs/for-ops/console/shortcuts/index.html | 4 ++-- docs/for-ops/console/teams/index.html | 4 ++-- docs/for-ops/console/workloads/index.html | 4 ++-- docs/for-ops/how-to/backups/index.html | 4 ++-- docs/for-ops/how-to/core-only/index.html | 4 ++-- docs/for-ops/how-to/dev-catalog/index.html | 4 ++-- docs/for-ops/how-to/ingress-classes/index.html | 4 ++-- docs/for-ops/how-to/overview/index.html | 4 ++-- docs/for-ops/how-to/switch-to-dns/index.html | 4 ++-- docs/for-ops/how-to/use-team-admin/index.html | 4 ++-- docs/for-ops/sre/daily/index.html | 4 ++-- docs/for-ops/sre/overview/index.html | 4 ++-- docs/for-ops/sre/troubleshooting/index.html | 4 ++-- docs/for-ops/sre/upgrades/index.html | 4 ++-- docs/get-started/activation/index.html | 4 ++-- docs/get-started/chart/index.html | 4 ++-- docs/get-started/installation/aws/index.html | 6 +++--- docs/get-started/installation/azure/index.html | 4 ++-- docs/get-started/installation/byo-wildcard-cert/index.html | 4 ++-- docs/get-started/installation/civo/index.html | 4 ++-- docs/get-started/installation/custom/index.html | 4 ++-- docs/get-started/installation/digitalocean/index.html | 4 ++-- docs/get-started/installation/entrypoint/index.html | 4 ++-- docs/get-started/installation/gcp/index.html | 4 ++-- docs/get-started/installation/helm/index.html | 4 ++-- docs/get-started/installation/kms/index.html | 4 ++-- docs/get-started/installation/known-issues/index.html | 4 ++-- docs/get-started/installation/linode/index.html | 4 ++-- docs/get-started/installation/minikube/index.html | 4 ++-- docs/get-started/installation/oidc/index.html | 4 ++-- docs/get-started/installation/overview/index.html | 4 ++-- docs/get-started/installation/scaleway/index.html | 4 ++-- docs/get-started/installation/vultr/index.html | 4 ++-- .../deploy-workloads-argo-cd-otomi-kubernetes/index.html | 4 ++-- docs/get-started/labs/lab-1/index.html | 4 ++-- docs/get-started/labs/lab-11/index.html | 4 ++-- docs/get-started/labs/lab-12/index.html | 4 ++-- docs/get-started/labs/lab-13/index.html | 4 ++-- docs/get-started/labs/lab-14/index.html | 4 ++-- docs/get-started/labs/lab-15/index.html | 4 ++-- docs/get-started/labs/lab-16/index.html | 4 ++-- docs/get-started/labs/lab-17/index.html | 4 ++-- docs/get-started/labs/lab-18/index.html | 4 ++-- docs/get-started/labs/lab-19/index.html | 4 ++-- docs/get-started/labs/lab-2/index.html | 4 ++-- docs/get-started/labs/lab-20/index.html | 4 ++-- docs/get-started/labs/lab-21/index.html | 4 ++-- docs/get-started/labs/lab-22/index.html | 4 ++-- docs/get-started/labs/lab-23/index.html | 4 ++-- docs/get-started/labs/lab-24/index.html | 4 ++-- docs/get-started/labs/lab-25/index.html | 4 ++-- docs/get-started/labs/lab-26/index.html | 4 ++-- docs/get-started/labs/lab-27/index.html | 4 ++-- docs/get-started/labs/lab-28/index.html | 4 ++-- docs/get-started/labs/lab-29/index.html | 4 ++-- docs/get-started/labs/lab-3/index.html | 4 ++-- docs/get-started/labs/lab-30/index.html | 4 ++-- docs/get-started/labs/lab-31/index.html | 4 ++-- docs/get-started/labs/lab-32/index.html | 4 ++-- docs/get-started/labs/lab-4/index.html | 4 ++-- docs/get-started/labs/lab-5/index.html | 4 ++-- docs/get-started/labs/lab-6/index.html | 4 ++-- docs/get-started/labs/lab-7/index.html | 4 ++-- docs/get-started/labs/lab-8/index.html | 4 ++-- docs/get-started/labs/lab-9/index.html | 4 ++-- docs/get-started/labs/overview/index.html | 4 ++-- docs/get-started/overview/index.html | 4 ++-- docs/get-started/prerequisites/index.html | 4 ++-- docs/get-started/promotions/index.html | 4 ++-- docs/tutorials/overview/index.html | 4 ++-- docs/tutorials/tutorial-1/index.html | 4 ++-- docs/tutorials/tutorial-10/index.html | 4 ++-- docs/tutorials/tutorial-2/index.html | 4 ++-- docs/tutorials/tutorial-3/index.html | 4 ++-- docs/tutorials/tutorial-4/index.html | 4 ++-- docs/tutorials/tutorial-5/index.html | 4 ++-- docs/tutorials/tutorial-6/index.html | 4 ++-- docs/tutorials/tutorial-7/index.html | 4 ++-- docs/tutorials/tutorial-8/index.html | 4 ++-- docs/tutorials/tutorial-9/index.html | 4 ++-- docs/tutorials/tutorials/create-k8s-service/index.html | 4 ++-- docs/tutorials/tutorials/create-knative-service/index.html | 4 ++-- docs/tutorials/tutorials/create-ksvc-otomi/index.html | 4 ++-- docs/tutorials/tutorials/use-secret/index.html | 4 ++-- index.html | 4 ++-- product/architecture/index.html | 6 +++--- product/eula/v1/index.html | 6 +++--- product/faq/index.html | 6 +++--- product/introduction/index.html | 6 +++--- product/roadmap/index.html | 6 +++--- product/use-cases/adoption-framework/index.html | 6 +++--- product/use-cases/ci-cd/index.html | 6 +++--- product/use-cases/edge/index.html | 6 +++--- product/use-cases/multi-cluster/index.html | 6 +++--- product/use-cases/multi-tenancy/index.html | 6 +++--- product/use-cases/overview/index.html | 6 +++--- product/use-cases/serverless/index.html | 6 +++--- search/index.html | 4 ++-- 206 files changed, 411 insertions(+), 411 deletions(-) rename assets/js/{042c512d.6637f92d.js => 042c512d.81b69616.js} (98%) rename assets/js/{21fbcd7c.2be8af33.js => 21fbcd7c.1b4c4acb.js} (99%) rename assets/js/{2d9c895d.b7386f49.js => 2d9c895d.cfb99443.js} (98%) rename assets/js/{3d235714.ed09bcde.js => 3d235714.dab34a6e.js} (99%) rename assets/js/{4f01d7c7.83164f21.js => 4f01d7c7.f12f572f.js} (99%) rename assets/js/{5db37859.9f73e243.js => 5db37859.9b4fc439.js} (98%) rename assets/js/{70b0dc77.fde1e8cb.js => 70b0dc77.869b8552.js} (98%) rename assets/js/{73148982.041cb4ba.js => 73148982.8d276d5c.js} (99%) rename assets/js/{8f69df39.129b4e23.js => 8f69df39.935e1adc.js} (81%) rename assets/js/{b0500dc6.f5f3cc95.js => b0500dc6.81ecb920.js} (99%) rename assets/js/{b4b7b186.4ab79471.js => b4b7b186.0e2a4edc.js} (98%) rename assets/js/{c1cd9779.f2b1173b.js => c1cd9779.f594a6c7.js} (99%) rename assets/js/{c642c7e8.2136c116.js => c642c7e8.142d5454.js} (98%) rename assets/js/{d673e682.87a4a0f3.js => d673e682.47198934.js} (98%) rename assets/js/{e878c199.d13050b3.js => e878c199.93aca584.js} (99%) rename assets/js/{efe7c983.9241def9.js => efe7c983.20929ee8.js} (99%) rename assets/js/{f1abdd8c.ed966a4c.js => f1abdd8c.5cf402fb.js} (99%) rename assets/js/{runtime~main.110a1fa6.js => runtime~main.f463275f.js} (73%) diff --git a/404.html b/404.html index ee900ab25..506cf6066 100644 --- a/404.html +++ b/404.html @@ -14,13 +14,13 @@ - +
Skip to main content

Page Not Found

We could not find what you were looking for.

Please contact the owner of the site that linked you to the original URL and let them know their link is broken.

- + \ No newline at end of file diff --git a/assets/js/042c512d.6637f92d.js b/assets/js/042c512d.81b69616.js similarity index 98% rename from assets/js/042c512d.6637f92d.js rename to assets/js/042c512d.81b69616.js index 40bfd7918..0abed3bd4 100644 --- a/assets/js/042c512d.6637f92d.js +++ b/assets/js/042c512d.81b69616.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2018],{3905:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>d});var i=r(7294);function n(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function l(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);t&&(i=i.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,i)}return r}function a(e){for(var t=1;t=0||(n[r]=e[r]);return n}(e,t);if(Object.getOwnPropertySymbols){var l=Object.getOwnPropertySymbols(e);for(i=0;i=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(n[r]=e[r])}return n}var o=i.createContext({}),u=function(e){var t=i.useContext(o),r=t;return e&&(r="function"==typeof e?e(t):a(a({},t),e)),r},c=function(e){var t=u(e.components);return i.createElement(o.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return i.createElement(i.Fragment,{},t)}},m=i.forwardRef((function(e,t){var r=e.components,n=e.mdxType,l=e.originalType,o=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),m=u(r),d=n,b=m["".concat(o,".").concat(d)]||m[d]||p[d]||l;return r?i.createElement(b,a(a({ref:t},c),{},{components:r})):i.createElement(b,a({ref:t},c))}));function d(e,t){var r=arguments,n=t&&t.mdxType;if("string"==typeof e||n){var l=r.length,a=new Array(l);a[0]=m;var s={};for(var o in t)hasOwnProperty.call(t,o)&&(s[o]=t[o]);s.originalType=e,s.mdxType="string"==typeof e?e:n,a[1]=s;for(var u=2;u{r.r(t),r.d(t,{assets:()=>o,contentTitle:()=>a,default:()=>p,frontMatter:()=>l,metadata:()=>s,toc:()=>u});var i=r(7462),n=(r(7294),r(3905));const l={slug:"multi-cluster",title:"Multi-cluster observability",sidebar_label:"Multi-cluster observability"},a=void 0,s={unversionedId:"use-cases/multi-cluster",id:"use-cases/multi-cluster",title:"Multi-cluster observability",description:"Introduction",source:"@site/product/use-cases/multi-cluster.md",sourceDirName:"use-cases",slug:"/use-cases/multi-cluster",permalink:"/product/use-cases/multi-cluster",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/multi-cluster.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"multi-cluster",title:"Multi-cluster observability",sidebar_label:"Multi-cluster observability"}},o={},u=[{value:"Introduction",id:"introduction",level:2},{value:"Multi-cluster observability with Otomi",id:"multi-cluster-observability-with-otomi",level:2}],c={toc:u};function p(e){let{components:t,...l}=e;return(0,n.kt)("wrapper",(0,i.Z)({},c,l,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h2",{id:"introduction"},"Introduction"),(0,n.kt)("p",null,"Using multiple Kubernetes clusters can have advantages based on your requirements. Some of the benefits of running multiple Kubernetes clusters are:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"High availability: When one cluster fails, the other cluster(s) can take the load. Losing one cluster when your applications are appropriately spread across several other clusters is much better than losing a single cluster with everything on it"),(0,n.kt)("li",{parentName:"ul"},"Better end user experience: Splitting workloads can improve performance and reduce latency by providing users with a geographically close environment"),(0,n.kt)("li",{parentName:"ul"},"Separate development and production clusters to reduce the risk of being served beta or non-production code versions")),(0,n.kt)("p",null,"But from a technical perspective, managing multiple Kubernetes clusters is more complex than managing a single cluster. For effective multi-cluster management, a \u201csingle pane of glass\u201d with centralized real-time monitoring, time series comparisons across and within clusters and high availability is essential for teams operating with multiple clusters and multiple providers."),(0,n.kt)("h2",{id:"multi-cluster-observability-with-otomi"},"Multi-cluster observability with Otomi"),(0,n.kt)("p",null,"The following image shows a multi-cluster observability setup using Otomi:"),(0,n.kt)("p",null,(0,n.kt)("img",{alt:"multi-cluster",src:r(1195).Z,width:"1556",height:"1226"})),(0,n.kt)("ol",null,(0,n.kt)("li",{parentName:"ol"},"Aggregation of metrics from workload clusters for Prometheus high availability and single pane of glass"),(0,n.kt)("li",{parentName:"ol"},"Multi-cluster log aggregation"),(0,n.kt)("li",{parentName:"ol"},"Preconfigured multi-cluster dashboards"),(0,n.kt)("li",{parentName:"ol"},"Multi-cluster alerting")),(0,n.kt)("p",null,"This multi-cluster setup can be expanded with:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Running Harbor on the management cluster to provide image and chart registries for the workload clusters"),(0,n.kt)("li",{parentName:"ul"},"Replicate workload cluster Git repositories to the management cluster Git repository"),(0,n.kt)("li",{parentName:"ul"},"Deploy multiple application clusters based on a single cluster profile")))}p.isMDXComponent=!0},1195:(e,t,r)=>{r.d(t,{Z:()=>i});const i=r.p+"assets/images/multi-cluster-dd1d21f51c8f0d0623e575b53e84568d.png"}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2018],{3905:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>d});var i=r(7294);function n(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function l(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);t&&(i=i.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,i)}return r}function a(e){for(var t=1;t=0||(n[r]=e[r]);return n}(e,t);if(Object.getOwnPropertySymbols){var l=Object.getOwnPropertySymbols(e);for(i=0;i=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(n[r]=e[r])}return n}var o=i.createContext({}),u=function(e){var t=i.useContext(o),r=t;return e&&(r="function"==typeof e?e(t):a(a({},t),e)),r},c=function(e){var t=u(e.components);return i.createElement(o.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return i.createElement(i.Fragment,{},t)}},m=i.forwardRef((function(e,t){var r=e.components,n=e.mdxType,l=e.originalType,o=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),m=u(r),d=n,b=m["".concat(o,".").concat(d)]||m[d]||p[d]||l;return r?i.createElement(b,a(a({ref:t},c),{},{components:r})):i.createElement(b,a({ref:t},c))}));function d(e,t){var r=arguments,n=t&&t.mdxType;if("string"==typeof e||n){var l=r.length,a=new Array(l);a[0]=m;var s={};for(var o in t)hasOwnProperty.call(t,o)&&(s[o]=t[o]);s.originalType=e,s.mdxType="string"==typeof e?e:n,a[1]=s;for(var u=2;u{r.r(t),r.d(t,{assets:()=>o,contentTitle:()=>a,default:()=>p,frontMatter:()=>l,metadata:()=>s,toc:()=>u});var i=r(7462),n=(r(7294),r(3905));const l={slug:"multi-cluster",title:"Multi-cluster observability",sidebar_label:"Multi-cluster observability"},a=void 0,s={unversionedId:"use-cases/multi-cluster",id:"use-cases/multi-cluster",title:"Multi-cluster observability",description:"Introduction",source:"@site/product/use-cases/multi-cluster.md",sourceDirName:"use-cases",slug:"/use-cases/multi-cluster",permalink:"/product/use-cases/multi-cluster",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/multi-cluster.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"multi-cluster",title:"Multi-cluster observability",sidebar_label:"Multi-cluster observability"}},o={},u=[{value:"Introduction",id:"introduction",level:2},{value:"Multi-cluster observability with Otomi",id:"multi-cluster-observability-with-otomi",level:2}],c={toc:u};function p(e){let{components:t,...l}=e;return(0,n.kt)("wrapper",(0,i.Z)({},c,l,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h2",{id:"introduction"},"Introduction"),(0,n.kt)("p",null,"Using multiple Kubernetes clusters can have advantages based on your requirements. Some of the benefits of running multiple Kubernetes clusters are:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"High availability: When one cluster fails, the other cluster(s) can take the load. Losing one cluster when your applications are appropriately spread across several other clusters is much better than losing a single cluster with everything on it"),(0,n.kt)("li",{parentName:"ul"},"Better end user experience: Splitting workloads can improve performance and reduce latency by providing users with a geographically close environment"),(0,n.kt)("li",{parentName:"ul"},"Separate development and production clusters to reduce the risk of being served beta or non-production code versions")),(0,n.kt)("p",null,"But from a technical perspective, managing multiple Kubernetes clusters is more complex than managing a single cluster. For effective multi-cluster management, a \u201csingle pane of glass\u201d with centralized real-time monitoring, time series comparisons across and within clusters and high availability is essential for teams operating with multiple clusters and multiple providers."),(0,n.kt)("h2",{id:"multi-cluster-observability-with-otomi"},"Multi-cluster observability with Otomi"),(0,n.kt)("p",null,"The following image shows a multi-cluster observability setup using Otomi:"),(0,n.kt)("p",null,(0,n.kt)("img",{alt:"multi-cluster",src:r(1195).Z,width:"1556",height:"1226"})),(0,n.kt)("ol",null,(0,n.kt)("li",{parentName:"ol"},"Aggregation of metrics from workload clusters for Prometheus high availability and single pane of glass"),(0,n.kt)("li",{parentName:"ol"},"Multi-cluster log aggregation"),(0,n.kt)("li",{parentName:"ol"},"Preconfigured multi-cluster dashboards"),(0,n.kt)("li",{parentName:"ol"},"Multi-cluster alerting")),(0,n.kt)("p",null,"This multi-cluster setup can be expanded with:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Running Harbor on the management cluster to provide image and chart registries for the workload clusters"),(0,n.kt)("li",{parentName:"ul"},"Replicate workload cluster Git repositories to the management cluster Git repository"),(0,n.kt)("li",{parentName:"ul"},"Deploy multiple application clusters based on a single cluster profile")))}p.isMDXComponent=!0},1195:(e,t,r)=>{r.d(t,{Z:()=>i});const i=r.p+"assets/images/multi-cluster-dd1d21f51c8f0d0623e575b53e84568d.png"}}]); \ No newline at end of file diff --git a/assets/js/21fbcd7c.2be8af33.js b/assets/js/21fbcd7c.1b4c4acb.js similarity index 99% rename from assets/js/21fbcd7c.2be8af33.js rename to assets/js/21fbcd7c.1b4c4acb.js index 6e4fee187..f19bcb828 100644 --- a/assets/js/21fbcd7c.2be8af33.js +++ b/assets/js/21fbcd7c.1b4c4acb.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[3563],{3905:(t,e,a)=>{a.d(e,{Zo:()=>s,kt:()=>k});var r=a(7294);function n(t,e,a){return e in t?Object.defineProperty(t,e,{value:a,enumerable:!0,configurable:!0,writable:!0}):t[e]=a,t}function i(t,e){var a=Object.keys(t);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(t);e&&(r=r.filter((function(e){return Object.getOwnPropertyDescriptor(t,e).enumerable}))),a.push.apply(a,r)}return a}function o(t){for(var e=1;e=0||(n[a]=t[a]);return n}(t,e);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(t);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(t,a)&&(n[a]=t[a])}return n}var p=r.createContext({}),m=function(t){var e=r.useContext(p),a=e;return t&&(a="function"==typeof t?t(e):o(o({},e),t)),a},s=function(t){var e=m(t.components);return r.createElement(p.Provider,{value:e},t.children)},c={inlineCode:"code",wrapper:function(t){var e=t.children;return r.createElement(r.Fragment,{},e)}},d=r.forwardRef((function(t,e){var a=t.components,n=t.mdxType,i=t.originalType,p=t.parentName,s=l(t,["components","mdxType","originalType","parentName"]),d=m(a),k=n,u=d["".concat(p,".").concat(k)]||d[k]||c[k]||i;return a?r.createElement(u,o(o({ref:e},s),{},{components:a})):r.createElement(u,o({ref:e},s))}));function k(t,e){var a=arguments,n=e&&e.mdxType;if("string"==typeof t||n){var i=a.length,o=new Array(i);o[0]=d;var l={};for(var p in e)hasOwnProperty.call(e,p)&&(l[p]=e[p]);l.originalType=t,l.mdxType="string"==typeof t?t:n,o[1]=l;for(var m=2;m{a.r(e),a.d(e,{assets:()=>p,contentTitle:()=>o,default:()=>c,frontMatter:()=>i,metadata:()=>l,toc:()=>m});var r=a(7462),n=(a(7294),a(3905));const i={slug:"architecture",title:"Otomi Projects",sidebar_label:"Otomi Projects"},o=void 0,l={unversionedId:"architecture",id:"architecture",title:"Otomi Projects",description:"Otomi consists out of the following projects:",source:"@site/product/architecture.md",sourceDirName:".",slug:"/architecture",permalink:"/product/architecture",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/architecture.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"architecture",title:"Otomi Projects",sidebar_label:"Otomi Projects"},sidebar:"mainSidebar",previous:{title:"Why Otomi",permalink:"/product/introduction"},next:{title:"Roadmap",permalink:"/product/roadmap"}},p={},m=[{value:"Otomi Core",id:"otomi-core",level:2},{value:"Integrated K8s applications",id:"integrated-k8s-applications",level:3},{value:"Catagories",id:"catagories",level:3},{value:"Advanced ingress architecture as its core",id:"advanced-ingress-architecture-as-its-core",level:3},{value:"Otomi Tasks",id:"otomi-tasks",level:2},{value:"Otomi Clients",id:"otomi-clients",level:2},{value:"Otomi API",id:"otomi-api",level:2},{value:"Otomi Console",id:"otomi-console",level:2}],s={toc:m};function c(t){let{components:e,...i}=t;return(0,n.kt)("wrapper",(0,r.Z)({},s,i,{components:e,mdxType:"MDXLayout"}),(0,n.kt)("p",null,"Otomi consists out of the following projects:"),(0,n.kt)("table",null,(0,n.kt)("thead",{parentName:"table"},(0,n.kt)("tr",{parentName:"thead"},(0,n.kt)("th",{parentName:"tr",align:null},"Project"),(0,n.kt)("th",{parentName:"tr",align:null},"open source"))),(0,n.kt)("tbody",{parentName:"table"},(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-core"},"otomi-core")),(0,n.kt)("td",{parentName:"tr",align:null},"Yes")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-tasks"},"otomi-tasks")),(0,n.kt)("td",{parentName:"tr",align:null},"Yes")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-clients"},"otomi-clients")),(0,n.kt)("td",{parentName:"tr",align:null},"Yes")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-console"},"otomi-console")),(0,n.kt)("td",{parentName:"tr",align:null},"No")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-api"},"otomi-api")),(0,n.kt)("td",{parentName:"tr",align:null},"No")))),(0,n.kt)("h2",{id:"otomi-core"},"Otomi Core"),(0,n.kt)("p",null,"Otomi Core contains all the integrated applications and is made available (per release) as a container image."),(0,n.kt)("p",null,"Otomi Core also contains the source code for Otomi CLI. Otomi CLI can be used for advanced initial configuration (bootstrapping), deployment, sync, push, template validation, and much more."),(0,n.kt)("h3",{id:"integrated-k8s-applications"},"Integrated K8s applications"),(0,n.kt)("p",null,"Otomi Core is the heart of Otomi and contains a suite of the following integrated Kubernetes applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/istio/istio"},"Istio"),": The service mesh framework with end-to-end transit encryption"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/keycloak/keycloak"},"Keycloak"),": Identity and access management for modern applications and services"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/cert-manager/cert-manager"},"Cert Manager")," - Bring your own wildcard certificate or request one from Let's Encrypt"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/kubernetes/ingress-nginx"},"Nginx Ingress Controller"),": Ingress controller for Kubernetes"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/kubernetes-sigs/external-dns"},"External DNS"),": Synchronize exposed ingresses with DNS providers"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/harness/drone"},"Drone"),": Continuous integration platform built on Docker"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/go-gitea/gitea"},"Gitea"),": Self-hosted Git service"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/vmware-tanzu/velero"},"Velero"),": Back up and restore your Kubernetes cluster resources and persistent volumes"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/argoproj/argo-cd"},"Argo CD"),": Declarative continuous deployment"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/knative/serving"},"Knative"),": Deploy and manage serverless workloads"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/GoogleContainerTools/kaniko"},"Kaniko"),": Build container images from a Dockerfile"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/prometheus/prometheus"},"Prometheus"),": Collecting container application metrics"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/grafana/grafana"},"Grafana"),": Visualize metrics, logs, and traces from multiple sources"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/grafana/loki"},"Grafana Loki"),": Collecting container application logs"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/goharbor/harbor"},"Harbor"),": Container image registry with role-based access control, image scanning, and image signing"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/hashicorp/vault"},"HashiCorp Vault"),": Manage Secrets and Protect Sensitive Data"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/open-policy-agent/gatekeeper"},"OPA/Gatekeeper"),": Policy-based control for cloud-native environments"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/jaegertracing/jaeger"},"Jaeger"),": End-to-end distributed tracing and monitor for complex distributed systems"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/kiali/kiali"},"Kiali"),": Observe Istio service mesh relations and connections"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/minio/minio"},"Minio"),": High performance Object Storage compatible with Amazon S3 cloud storage service"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/aquasecurity/trivy-operator"},"Trivy"),": Kubernetes-native security toolkit"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/thanos-io/thanos"},"Thanos"),": HA Prometheus setup with long term storage capabilities"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/falcosecurity/falco"},"Falco"),": Cloud Native Runtime Security"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/opencost/opencost"},"Opencost"),": Cost monitoring for Kubernetes"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/tektoncd/pipeline"},"Tekton Pipeline"),": K8s-style resources for declaring CI/CD pipelines"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/tektoncd/triggers"},"Tekton Triggers"),": Trigger pipelines from event payloads"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/tektoncd/dashboard"},"Tekton dashboard"),": Web-based UI for Tekton Pipelines and Tekton Triggers"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/paketo-buildpacks"},"Paketo build packs"),": Cloud Native Buildpack implementations for popular programming language ecosystems"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/cloudnative-pg/cloudnative-pg"},"Cloudnative-pg"),": Open source operator designed to manage PostgreSQL workloads"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/grafana/tempo"},"Grafana Tempo"),": High-scale distributed tracing backend"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/open-telemetry/opentelemetry-operator"},"OpenTelemetry"),": Instrument, generate, collect, and export telemetry data to help you analyze your software\u2019s performance and behavior")),(0,n.kt)("h3",{id:"catagories"},"Catagories"),(0,n.kt)("p",null,"Otomi contains four catagories of integrated K8s applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Core applications: applications that are activated by default"),(0,n.kt)("li",{parentName:"ul"},"Shared applications: applications that are shared between teams. Shared applications are user-, and role-aware or not (user is anonymous)"),(0,n.kt)("li",{parentName:"ul"},"Team applications: applications with a dedicated instance per team"),(0,n.kt)("li",{parentName:"ul"},"Optional applications: applications that are optional and can be activated by the platform admin")),(0,n.kt)("p",null,"The following table shows all integrated applications:"),(0,n.kt)("table",null,(0,n.kt)("thead",{parentName:"table"},(0,n.kt)("tr",{parentName:"thead"},(0,n.kt)("th",{parentName:"tr",align:"left"},"Application"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Core"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Shared"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Team"),(0,n.kt)("th",{parentName:"tr",align:"center"},"User/role-aware"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Optional"))),(0,n.kt)("tbody",{parentName:"table"},(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Istio"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Ingress NGINX Controller"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Knative"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/keycloak"},"KeyCloak")),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Prometheus Server"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Prometheus kube state metrics"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Alertmanager"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Grafana/Loki"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/gatekeeper"},"Gatekeeper Operator")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/vault"},"Hashicorp Vault")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/harbor"},"Harbor")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/drone"},"Drone")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Gitea"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Httpbin"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Jeager"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Kiali"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Velero"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Minio"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Opencost"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Tekton Pipeline"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Trivy Operator"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Cloudnative-pg"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"})))),(0,n.kt)("h3",{id:"advanced-ingress-architecture-as-its-core"},"Advanced ingress architecture as its core"),(0,n.kt)("p",null,"Otomi by default installs and configures an advanced ingress architecture. Ingress for a service can be configured using Otomi Services. The following figure shows the ingress and SSO architecture."),(0,n.kt)("p",null,(0,n.kt)("img",{alt:"img/ingress-overview",src:a(2701).Z,width:"1149",height:"828"})),(0,n.kt)("p",null,"The ingress & SSO architecture overview explained:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"(optional) an external gateway is used for termination of external traffic (e.g. an Azure Application Gateway or an AWS Application Load Balancer)."),(0,n.kt)("li",{parentName:"ul"},"2 Ingress NGINX controllers are deployed, one for public access and one for authenticated access."),(0,n.kt)("li",{parentName:"ul"},"Authenticated (SSO) access is handled by an oauth2 proxy and KeyCloak. The user logs in using the Otomi custom KeyCloak login page. "),(0,n.kt)("li",{parentName:"ul"},"KeyCloak is configured with an external IDP (optional) or uses local accounts. After authentication, KeyCloak provides a normalized JWT token. The JWT token is used by integrated core applications (providing user and role information) and team services configured with SSO"),(0,n.kt)("li",{parentName:"ul"},"4 Istio (ingress) gateways are provisioned: ")),(0,n.kt)("ol",null,(0,n.kt)("li",{parentName:"ol"},"a public gateway for routing public (non authenticated traffic to a service)"),(0,n.kt)("li",{parentName:"ol"},"an authentication gateway to route authenticated traffic to a service"),(0,n.kt)("li",{parentName:"ol"},"a local gateway (for local cluster routing)"),(0,n.kt)("li",{parentName:"ol"},"a Knative gateway to route traffic to Knative services")),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"For each service a Istio virtual service is configured."),(0,n.kt)("li",{parentName:"ul"},"One egress gateway is provisioned for all egress traffic (network policies allow all egress traffic).")),(0,n.kt)("h2",{id:"otomi-tasks"},"Otomi Tasks"),(0,n.kt)("p",null,"Otomi Tasks contains a set of Kubernetes jobs and teh Otomi Operator. The jobs and Operator ensure that the configuration of applications integrated in Otomi are always equal to the desired-state configuration (see Otomi Values). An example: If a team is created via Otomi Console (in combination with Otomi API), Otomi Tasks ensures that a project is created for the new team in Harbor, the access to the project in Harbor is configured, a robot account (that can be used to push images to the project registry) is created and that a pull secret is created in the namespace of the team."),(0,n.kt)("p",null,"Otomi Tasks is currently used to configure the following applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"KeyCloak"),(0,n.kt)("li",{parentName:"ul"},"Harbor"),(0,n.kt)("li",{parentName:"ul"},"Gitea"),(0,n.kt)("li",{parentName:"ul"},"Drone"),(0,n.kt)("li",{parentName:"ul"},"Otomi (copy-certs and wait-for)")),(0,n.kt)("h2",{id:"otomi-clients"},"Otomi Clients"),(0,n.kt)("p",null,"A factory to build and publish openapi clients used in the redkubes/otomi-tasks repo."),(0,n.kt)("p",null,"Otomi Clients is currently used to generate openapi clients for the following applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"KeyCloak"),(0,n.kt)("li",{parentName:"ul"},"Harbor"),(0,n.kt)("li",{parentName:"ul"},"Gitea")),(0,n.kt)("h2",{id:"otomi-api"},"Otomi API"),(0,n.kt)("p",null,"Otomi API allows for a controlled change of all Otomi Values, based on a configuration scheme and is the brain of Otomi. Otomi API runs as a container on each cluster running."),(0,n.kt)("admonition",{type:"info"},(0,n.kt)("p",{parentName:"admonition"},"Otomi API is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact ",(0,n.kt)("a",{parentName:"p",href:"https://redkubes.com/"},"Red Kubes")," for details on support and pricing for a full featured version.")),(0,n.kt)("h2",{id:"otomi-console"},"Otomi Console"),(0,n.kt)("p",null,"Otomi Console is the User Interface of Otomi. Otomi Console communicates with Otomi API for reading and changing Otomi Values configuration. Otomi Console also offers (via the Otomi Apps option) shortcuts to the UI of the various integrated applications."),(0,n.kt)("admonition",{type:"info"},(0,n.kt)("p",{parentName:"admonition"},"Otomi Console is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact ",(0,n.kt)("a",{parentName:"p",href:"https://redkubes.com/"},"Red Kubes")," for details on support and pricing for a full featured version.")))}c.isMDXComponent=!0},2701:(t,e,a)=>{a.d(e,{Z:()=>r});const r=a.p+"assets/images/ingress-overview-419bc5e7be19dafdebd9a8ec6b04a3b1.svg"}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[3563],{3905:(t,e,a)=>{a.d(e,{Zo:()=>s,kt:()=>k});var r=a(7294);function n(t,e,a){return e in t?Object.defineProperty(t,e,{value:a,enumerable:!0,configurable:!0,writable:!0}):t[e]=a,t}function i(t,e){var a=Object.keys(t);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(t);e&&(r=r.filter((function(e){return Object.getOwnPropertyDescriptor(t,e).enumerable}))),a.push.apply(a,r)}return a}function o(t){for(var e=1;e=0||(n[a]=t[a]);return n}(t,e);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(t);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(t,a)&&(n[a]=t[a])}return n}var p=r.createContext({}),m=function(t){var e=r.useContext(p),a=e;return t&&(a="function"==typeof t?t(e):o(o({},e),t)),a},s=function(t){var e=m(t.components);return r.createElement(p.Provider,{value:e},t.children)},c={inlineCode:"code",wrapper:function(t){var e=t.children;return r.createElement(r.Fragment,{},e)}},d=r.forwardRef((function(t,e){var a=t.components,n=t.mdxType,i=t.originalType,p=t.parentName,s=l(t,["components","mdxType","originalType","parentName"]),d=m(a),k=n,u=d["".concat(p,".").concat(k)]||d[k]||c[k]||i;return a?r.createElement(u,o(o({ref:e},s),{},{components:a})):r.createElement(u,o({ref:e},s))}));function k(t,e){var a=arguments,n=e&&e.mdxType;if("string"==typeof t||n){var i=a.length,o=new Array(i);o[0]=d;var l={};for(var p in e)hasOwnProperty.call(e,p)&&(l[p]=e[p]);l.originalType=t,l.mdxType="string"==typeof t?t:n,o[1]=l;for(var m=2;m{a.r(e),a.d(e,{assets:()=>p,contentTitle:()=>o,default:()=>c,frontMatter:()=>i,metadata:()=>l,toc:()=>m});var r=a(7462),n=(a(7294),a(3905));const i={slug:"architecture",title:"Otomi Projects",sidebar_label:"Otomi Projects"},o=void 0,l={unversionedId:"architecture",id:"architecture",title:"Otomi Projects",description:"Otomi consists out of the following projects:",source:"@site/product/architecture.md",sourceDirName:".",slug:"/architecture",permalink:"/product/architecture",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/architecture.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"architecture",title:"Otomi Projects",sidebar_label:"Otomi Projects"},sidebar:"mainSidebar",previous:{title:"Why Otomi",permalink:"/product/introduction"},next:{title:"Roadmap",permalink:"/product/roadmap"}},p={},m=[{value:"Otomi Core",id:"otomi-core",level:2},{value:"Integrated K8s applications",id:"integrated-k8s-applications",level:3},{value:"Catagories",id:"catagories",level:3},{value:"Advanced ingress architecture as its core",id:"advanced-ingress-architecture-as-its-core",level:3},{value:"Otomi Tasks",id:"otomi-tasks",level:2},{value:"Otomi Clients",id:"otomi-clients",level:2},{value:"Otomi API",id:"otomi-api",level:2},{value:"Otomi Console",id:"otomi-console",level:2}],s={toc:m};function c(t){let{components:e,...i}=t;return(0,n.kt)("wrapper",(0,r.Z)({},s,i,{components:e,mdxType:"MDXLayout"}),(0,n.kt)("p",null,"Otomi consists out of the following projects:"),(0,n.kt)("table",null,(0,n.kt)("thead",{parentName:"table"},(0,n.kt)("tr",{parentName:"thead"},(0,n.kt)("th",{parentName:"tr",align:null},"Project"),(0,n.kt)("th",{parentName:"tr",align:null},"open source"))),(0,n.kt)("tbody",{parentName:"table"},(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-core"},"otomi-core")),(0,n.kt)("td",{parentName:"tr",align:null},"Yes")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-tasks"},"otomi-tasks")),(0,n.kt)("td",{parentName:"tr",align:null},"Yes")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-clients"},"otomi-clients")),(0,n.kt)("td",{parentName:"tr",align:null},"Yes")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-console"},"otomi-console")),(0,n.kt)("td",{parentName:"tr",align:null},"No")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},(0,n.kt)("a",{parentName:"td",href:"https://github.com/redkubes/otomi-api"},"otomi-api")),(0,n.kt)("td",{parentName:"tr",align:null},"No")))),(0,n.kt)("h2",{id:"otomi-core"},"Otomi Core"),(0,n.kt)("p",null,"Otomi Core contains all the integrated applications and is made available (per release) as a container image."),(0,n.kt)("p",null,"Otomi Core also contains the source code for Otomi CLI. Otomi CLI can be used for advanced initial configuration (bootstrapping), deployment, sync, push, template validation, and much more."),(0,n.kt)("h3",{id:"integrated-k8s-applications"},"Integrated K8s applications"),(0,n.kt)("p",null,"Otomi Core is the heart of Otomi and contains a suite of the following integrated Kubernetes applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/istio/istio"},"Istio"),": The service mesh framework with end-to-end transit encryption"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/keycloak/keycloak"},"Keycloak"),": Identity and access management for modern applications and services"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/cert-manager/cert-manager"},"Cert Manager")," - Bring your own wildcard certificate or request one from Let's Encrypt"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/kubernetes/ingress-nginx"},"Nginx Ingress Controller"),": Ingress controller for Kubernetes"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/kubernetes-sigs/external-dns"},"External DNS"),": Synchronize exposed ingresses with DNS providers"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/harness/drone"},"Drone"),": Continuous integration platform built on Docker"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/go-gitea/gitea"},"Gitea"),": Self-hosted Git service"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/vmware-tanzu/velero"},"Velero"),": Back up and restore your Kubernetes cluster resources and persistent volumes"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/argoproj/argo-cd"},"Argo CD"),": Declarative continuous deployment"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/knative/serving"},"Knative"),": Deploy and manage serverless workloads"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/GoogleContainerTools/kaniko"},"Kaniko"),": Build container images from a Dockerfile"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/prometheus/prometheus"},"Prometheus"),": Collecting container application metrics"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/grafana/grafana"},"Grafana"),": Visualize metrics, logs, and traces from multiple sources"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/grafana/loki"},"Grafana Loki"),": Collecting container application logs"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/goharbor/harbor"},"Harbor"),": Container image registry with role-based access control, image scanning, and image signing"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/hashicorp/vault"},"HashiCorp Vault"),": Manage Secrets and Protect Sensitive Data"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/open-policy-agent/gatekeeper"},"OPA/Gatekeeper"),": Policy-based control for cloud-native environments"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/jaegertracing/jaeger"},"Jaeger"),": End-to-end distributed tracing and monitor for complex distributed systems"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/kiali/kiali"},"Kiali"),": Observe Istio service mesh relations and connections"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/minio/minio"},"Minio"),": High performance Object Storage compatible with Amazon S3 cloud storage service"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/aquasecurity/trivy-operator"},"Trivy"),": Kubernetes-native security toolkit"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/thanos-io/thanos"},"Thanos"),": HA Prometheus setup with long term storage capabilities"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/falcosecurity/falco"},"Falco"),": Cloud Native Runtime Security"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/opencost/opencost"},"Opencost"),": Cost monitoring for Kubernetes"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/tektoncd/pipeline"},"Tekton Pipeline"),": K8s-style resources for declaring CI/CD pipelines"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/tektoncd/triggers"},"Tekton Triggers"),": Trigger pipelines from event payloads"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/tektoncd/dashboard"},"Tekton dashboard"),": Web-based UI for Tekton Pipelines and Tekton Triggers"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/paketo-buildpacks"},"Paketo build packs"),": Cloud Native Buildpack implementations for popular programming language ecosystems"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/cloudnative-pg/cloudnative-pg"},"Cloudnative-pg"),": Open source operator designed to manage PostgreSQL workloads"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/grafana/tempo"},"Grafana Tempo"),": High-scale distributed tracing backend"),(0,n.kt)("li",{parentName:"ul"},(0,n.kt)("a",{parentName:"li",href:"https://github.com/open-telemetry/opentelemetry-operator"},"OpenTelemetry"),": Instrument, generate, collect, and export telemetry data to help you analyze your software\u2019s performance and behavior")),(0,n.kt)("h3",{id:"catagories"},"Catagories"),(0,n.kt)("p",null,"Otomi contains four catagories of integrated K8s applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Core applications: applications that are activated by default"),(0,n.kt)("li",{parentName:"ul"},"Shared applications: applications that are shared between teams. Shared applications are user-, and role-aware or not (user is anonymous)"),(0,n.kt)("li",{parentName:"ul"},"Team applications: applications with a dedicated instance per team"),(0,n.kt)("li",{parentName:"ul"},"Optional applications: applications that are optional and can be activated by the platform admin")),(0,n.kt)("p",null,"The following table shows all integrated applications:"),(0,n.kt)("table",null,(0,n.kt)("thead",{parentName:"table"},(0,n.kt)("tr",{parentName:"thead"},(0,n.kt)("th",{parentName:"tr",align:"left"},"Application"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Core"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Shared"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Team"),(0,n.kt)("th",{parentName:"tr",align:"center"},"User/role-aware"),(0,n.kt)("th",{parentName:"tr",align:"center"},"Optional"))),(0,n.kt)("tbody",{parentName:"table"},(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Istio"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Ingress NGINX Controller"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Knative"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/keycloak"},"KeyCloak")),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Prometheus Server"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Prometheus kube state metrics"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Alertmanager"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Grafana/Loki"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/gatekeeper"},"Gatekeeper Operator")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/vault"},"Hashicorp Vault")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/harbor"},"Harbor")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},(0,n.kt)("a",{parentName:"td",href:"/docs/apps/drone"},"Drone")),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Gitea"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"})),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Httpbin"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Jeager"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Kiali"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Velero"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Minio"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Opencost"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Tekton Pipeline"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Trivy Operator"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"},"X")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:"left"},"Cloudnative-pg"),(0,n.kt)("td",{parentName:"tr",align:"center"},"X"),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"}),(0,n.kt)("td",{parentName:"tr",align:"center"})))),(0,n.kt)("h3",{id:"advanced-ingress-architecture-as-its-core"},"Advanced ingress architecture as its core"),(0,n.kt)("p",null,"Otomi by default installs and configures an advanced ingress architecture. Ingress for a service can be configured using Otomi Services. The following figure shows the ingress and SSO architecture."),(0,n.kt)("p",null,(0,n.kt)("img",{alt:"img/ingress-overview",src:a(2701).Z,width:"1149",height:"828"})),(0,n.kt)("p",null,"The ingress & SSO architecture overview explained:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"(optional) an external gateway is used for termination of external traffic (e.g. an Azure Application Gateway or an AWS Application Load Balancer)."),(0,n.kt)("li",{parentName:"ul"},"2 Ingress NGINX controllers are deployed, one for public access and one for authenticated access."),(0,n.kt)("li",{parentName:"ul"},"Authenticated (SSO) access is handled by an oauth2 proxy and KeyCloak. The user logs in using the Otomi custom KeyCloak login page. "),(0,n.kt)("li",{parentName:"ul"},"KeyCloak is configured with an external IDP (optional) or uses local accounts. After authentication, KeyCloak provides a normalized JWT token. The JWT token is used by integrated core applications (providing user and role information) and team services configured with SSO"),(0,n.kt)("li",{parentName:"ul"},"4 Istio (ingress) gateways are provisioned: ")),(0,n.kt)("ol",null,(0,n.kt)("li",{parentName:"ol"},"a public gateway for routing public (non authenticated traffic to a service)"),(0,n.kt)("li",{parentName:"ol"},"an authentication gateway to route authenticated traffic to a service"),(0,n.kt)("li",{parentName:"ol"},"a local gateway (for local cluster routing)"),(0,n.kt)("li",{parentName:"ol"},"a Knative gateway to route traffic to Knative services")),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"For each service a Istio virtual service is configured."),(0,n.kt)("li",{parentName:"ul"},"One egress gateway is provisioned for all egress traffic (network policies allow all egress traffic).")),(0,n.kt)("h2",{id:"otomi-tasks"},"Otomi Tasks"),(0,n.kt)("p",null,"Otomi Tasks contains a set of Kubernetes jobs and teh Otomi Operator. The jobs and Operator ensure that the configuration of applications integrated in Otomi are always equal to the desired-state configuration (see Otomi Values). An example: If a team is created via Otomi Console (in combination with Otomi API), Otomi Tasks ensures that a project is created for the new team in Harbor, the access to the project in Harbor is configured, a robot account (that can be used to push images to the project registry) is created and that a pull secret is created in the namespace of the team."),(0,n.kt)("p",null,"Otomi Tasks is currently used to configure the following applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"KeyCloak"),(0,n.kt)("li",{parentName:"ul"},"Harbor"),(0,n.kt)("li",{parentName:"ul"},"Gitea"),(0,n.kt)("li",{parentName:"ul"},"Drone"),(0,n.kt)("li",{parentName:"ul"},"Otomi (copy-certs and wait-for)")),(0,n.kt)("h2",{id:"otomi-clients"},"Otomi Clients"),(0,n.kt)("p",null,"A factory to build and publish openapi clients used in the redkubes/otomi-tasks repo."),(0,n.kt)("p",null,"Otomi Clients is currently used to generate openapi clients for the following applications:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"KeyCloak"),(0,n.kt)("li",{parentName:"ul"},"Harbor"),(0,n.kt)("li",{parentName:"ul"},"Gitea")),(0,n.kt)("h2",{id:"otomi-api"},"Otomi API"),(0,n.kt)("p",null,"Otomi API allows for a controlled change of all Otomi Values, based on a configuration scheme and is the brain of Otomi. Otomi API runs as a container on each cluster running."),(0,n.kt)("admonition",{type:"info"},(0,n.kt)("p",{parentName:"admonition"},"Otomi API is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact ",(0,n.kt)("a",{parentName:"p",href:"https://redkubes.com/"},"Red Kubes")," for details on support and pricing for a full featured version.")),(0,n.kt)("h2",{id:"otomi-console"},"Otomi Console"),(0,n.kt)("p",null,"Otomi Console is the User Interface of Otomi. Otomi Console communicates with Otomi API for reading and changing Otomi Values configuration. Otomi Console also offers (via the Otomi Apps option) shortcuts to the UI of the various integrated applications."),(0,n.kt)("admonition",{type:"info"},(0,n.kt)("p",{parentName:"admonition"},"Otomi Console is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact ",(0,n.kt)("a",{parentName:"p",href:"https://redkubes.com/"},"Red Kubes")," for details on support and pricing for a full featured version.")))}c.isMDXComponent=!0},2701:(t,e,a)=>{a.d(e,{Z:()=>r});const r=a.p+"assets/images/ingress-overview-419bc5e7be19dafdebd9a8ec6b04a3b1.svg"}}]); \ No newline at end of file diff --git a/assets/js/2d9c895d.b7386f49.js b/assets/js/2d9c895d.cfb99443.js similarity index 98% rename from assets/js/2d9c895d.b7386f49.js rename to assets/js/2d9c895d.cfb99443.js index ff17aa499..91cbcca41 100644 --- a/assets/js/2d9c895d.b7386f49.js +++ b/assets/js/2d9c895d.cfb99443.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[5022],{3905:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>f});var n=r(7294);function o(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function a(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,n)}return r}function i(e){for(var t=1;t=0||(o[r]=e[r]);return o}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(o[r]=e[r])}return o}var l=n.createContext({}),u=function(e){var t=n.useContext(l),r=t;return e&&(r="function"==typeof e?e(t):i(i({},t),e)),r},c=function(e){var t=u(e.components);return n.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},d=n.forwardRef((function(e,t){var r=e.components,o=e.mdxType,a=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),d=u(r),f=o,v=d["".concat(l,".").concat(f)]||d[f]||p[f]||a;return r?n.createElement(v,i(i({ref:t},c),{},{components:r})):n.createElement(v,i({ref:t},c))}));function f(e,t){var r=arguments,o=t&&t.mdxType;if("string"==typeof e||o){var a=r.length,i=new Array(a);i[0]=d;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:o,i[1]=s;for(var u=2;u{r.r(t),r.d(t,{assets:()=>l,contentTitle:()=>i,default:()=>p,frontMatter:()=>a,metadata:()=>s,toc:()=>u});var n=r(7462),o=(r(7294),r(3905));const a={slug:"overview",title:"Use cases overview",sidebar_label:"Overview"},i=void 0,s={unversionedId:"use-cases/overview",id:"use-cases/overview",title:"Use cases overview",description:"Introduction",source:"@site/product/use-cases/overview.md",sourceDirName:"use-cases",slug:"/use-cases/overview",permalink:"/product/use-cases/overview",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/overview.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"overview",title:"Use cases overview",sidebar_label:"Overview"},sidebar:"mainSidebar",previous:{title:"FAQ",permalink:"/product/faq"},next:{title:"Adoption Framework",permalink:"/product/use-cases/adoption-framework"}},l={},u=[{value:"Introduction",id:"introduction",level:2},{value:"Adoption framework for Kubernetes",id:"adoption-framework-for-kubernetes",level:3},{value:"Multi-tenancy",id:"multi-tenancy",level:3},{value:"Serverless",id:"serverless",level:3},{value:"CD/CD",id:"cdcd",level:3}],c={toc:u};function p(e){let{components:t,...r}=e;return(0,o.kt)("wrapper",(0,n.Z)({},c,r,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h2",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,"Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. It contains a complete suite of pre-configured tools and guardrails to run containerized applications securely on any Kubernetes cluster in any cloud. In this section we'll dive a little deeper into some of the use cases Otomi supports."),(0,o.kt)("hr",null),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"Make sure everything is ready to get started")),(0,o.kt)("h3",{id:"adoption-framework-for-kubernetes"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/adoption-framework"},"Adoption framework for Kubernetes")),(0,o.kt)("p",null,"Use Otomi as an adoption framework to support migration to Kubernetes in an efficient and streamlined way."),(0,o.kt)("h3",{id:"multi-tenancy"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/multi-tenancy"},"Multi-tenancy")),(0,o.kt)("p",null,"Share a Kubernetes cluster and all the integrated tools with multiple tenants."),(0,o.kt)("h3",{id:"serverless"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/serverless"},"Serverless")),(0,o.kt)("p",null,"A landing zone for serverless applications."),(0,o.kt)("h3",{id:"cdcd"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/ci-cd"},"CD/CD")),(0,o.kt)("p",null,"Setup CI and CD capabilities."),(0,o.kt)("hr",null))}p.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[5022],{3905:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>f});var n=r(7294);function o(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function a(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,n)}return r}function i(e){for(var t=1;t=0||(o[r]=e[r]);return o}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(o[r]=e[r])}return o}var l=n.createContext({}),u=function(e){var t=n.useContext(l),r=t;return e&&(r="function"==typeof e?e(t):i(i({},t),e)),r},c=function(e){var t=u(e.components);return n.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},d=n.forwardRef((function(e,t){var r=e.components,o=e.mdxType,a=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),d=u(r),f=o,v=d["".concat(l,".").concat(f)]||d[f]||p[f]||a;return r?n.createElement(v,i(i({ref:t},c),{},{components:r})):n.createElement(v,i({ref:t},c))}));function f(e,t){var r=arguments,o=t&&t.mdxType;if("string"==typeof e||o){var a=r.length,i=new Array(a);i[0]=d;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:o,i[1]=s;for(var u=2;u{r.r(t),r.d(t,{assets:()=>l,contentTitle:()=>i,default:()=>p,frontMatter:()=>a,metadata:()=>s,toc:()=>u});var n=r(7462),o=(r(7294),r(3905));const a={slug:"overview",title:"Use cases overview",sidebar_label:"Overview"},i=void 0,s={unversionedId:"use-cases/overview",id:"use-cases/overview",title:"Use cases overview",description:"Introduction",source:"@site/product/use-cases/overview.md",sourceDirName:"use-cases",slug:"/use-cases/overview",permalink:"/product/use-cases/overview",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/overview.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"overview",title:"Use cases overview",sidebar_label:"Overview"},sidebar:"mainSidebar",previous:{title:"FAQ",permalink:"/product/faq"},next:{title:"Adoption Framework",permalink:"/product/use-cases/adoption-framework"}},l={},u=[{value:"Introduction",id:"introduction",level:2},{value:"Adoption framework for Kubernetes",id:"adoption-framework-for-kubernetes",level:3},{value:"Multi-tenancy",id:"multi-tenancy",level:3},{value:"Serverless",id:"serverless",level:3},{value:"CD/CD",id:"cdcd",level:3}],c={toc:u};function p(e){let{components:t,...r}=e;return(0,o.kt)("wrapper",(0,n.Z)({},c,r,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h2",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,"Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. It contains a complete suite of pre-configured tools and guardrails to run containerized applications securely on any Kubernetes cluster in any cloud. In this section we'll dive a little deeper into some of the use cases Otomi supports."),(0,o.kt)("hr",null),(0,o.kt)("p",null,(0,o.kt)("strong",{parentName:"p"},"Make sure everything is ready to get started")),(0,o.kt)("h3",{id:"adoption-framework-for-kubernetes"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/adoption-framework"},"Adoption framework for Kubernetes")),(0,o.kt)("p",null,"Use Otomi as an adoption framework to support migration to Kubernetes in an efficient and streamlined way."),(0,o.kt)("h3",{id:"multi-tenancy"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/multi-tenancy"},"Multi-tenancy")),(0,o.kt)("p",null,"Share a Kubernetes cluster and all the integrated tools with multiple tenants."),(0,o.kt)("h3",{id:"serverless"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/serverless"},"Serverless")),(0,o.kt)("p",null,"A landing zone for serverless applications."),(0,o.kt)("h3",{id:"cdcd"},(0,o.kt)("a",{parentName:"h3",href:"/product/use-cases/ci-cd"},"CD/CD")),(0,o.kt)("p",null,"Setup CI and CD capabilities."),(0,o.kt)("hr",null))}p.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/3d235714.ed09bcde.js b/assets/js/3d235714.dab34a6e.js similarity index 99% rename from assets/js/3d235714.ed09bcde.js rename to assets/js/3d235714.dab34a6e.js index 14dba88ea..d3c7a2b33 100644 --- a/assets/js/3d235714.ed09bcde.js +++ b/assets/js/3d235714.dab34a6e.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2117],{3905:(e,t,n)=>{n.d(t,{Zo:()=>c,kt:()=>f});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var l=r.createContext({}),p=function(e){var t=r.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},c=function(e){var t=p(e.components);return r.createElement(l.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},u=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),u=p(n),f=a,m=u["".concat(l,".").concat(f)]||u[f]||d[f]||o;return n?r.createElement(m,i(i({ref:t},c),{},{components:n})):r.createElement(m,i({ref:t},c))}));function f(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=u;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:a,i[1]=s;for(var p=2;p{n.r(t),n.d(t,{assets:()=>l,contentTitle:()=>i,default:()=>d,frontMatter:()=>o,metadata:()=>s,toc:()=>p});var r=n(7462),a=(n(7294),n(3905));const o={slug:"adoption-framework",title:"Otomi as adoption framework for Kubernetes",sidebar_label:"Adoption Framework"},i=void 0,s={unversionedId:"use-cases/adoption-framework",id:"use-cases/adoption-framework",title:"Otomi as adoption framework for Kubernetes",description:"What is an adoption framework for Kubernetes?",source:"@site/product/use-cases/adoption-framework.md",sourceDirName:"use-cases",slug:"/use-cases/adoption-framework",permalink:"/product/use-cases/adoption-framework",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/adoption-framework.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"adoption-framework",title:"Otomi as adoption framework for Kubernetes",sidebar_label:"Adoption Framework"},sidebar:"mainSidebar",previous:{title:"Overview",permalink:"/product/use-cases/overview"},next:{title:"Multi-tenancy",permalink:"/product/use-cases/multi-tenancy"}},l={},p=[{value:"What is an adoption framework for Kubernetes?",id:"what-is-an-adoption-framework-for-kubernetes",level:2},{value:"Why use an adoption framework like Otomi for Kubernetes",id:"why-use-an-adoption-framework-like-otomi-for-kubernetes",level:2},{value:"What are the capabilities of an adoption framework for Kubernetes?",id:"what-are-the-capabilities-of-an-adoption-framework-for-kubernetes",level:2}],c={toc:p};function d(e){let{components:t,...o}=e;return(0,a.kt)("wrapper",(0,r.Z)({},c,o,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h2",{id:"what-is-an-adoption-framework-for-kubernetes"},"What is an adoption framework for Kubernetes?"),(0,a.kt)("p",null,"A Kubernetes adoption framework can be used to support migration to Kubernetes in an efficient and streamlined way. The benefit of a Kubernetes adoption framework is that a number of required capabilities and configurations are established initially, which determine how containerized applications are going to be deployed, secured and operated. A Kubernetes adoption framework provides all the required controls following best practices in the areas of security, compliance, observability, CD, networking and self-service. All based on Infrastructure as Code."),(0,a.kt)("p",null,"A Kubernetes adoption framework is implemented differently for each organization. Each company has different requirements, has to meet different compliance requirements, and uses different cloud infrastructures. Creating a multi-/hybrid cloud Kubernetes landing zone requires a significant investment. Otomi can be used as a Kubernetes adoption framework to create a landing zone for containerized applications on any Kubernetes cluster in any cloud and can be tailored based on organization specific requirements."),(0,a.kt)("h2",{id:"why-use-an-adoption-framework-like-otomi-for-kubernetes"},"Why use an adoption framework like Otomi for Kubernetes"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Compliant With Security Regulations\nGiven that established parameters apply, developers operate within well-defined boundaries. This means that companies do not risk of running containerized workloads that differ from their compliance policy. Similarly, the IT manager is less concerned about compliance as it is embedded in the foundation of the IT infrastructure.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Speed \u200b\u200bAnd Scalability\nAs mentioned above, a migration to Kubernetes can happen more quickly with the help of an adoption framework. Preparation time is significantly reduced. Creating a compliant landigzone for Kubernetes can take up to 12 months (or even more) of work (if you have the required knowledge onboard). This time can be cut down to days with the use of Otomi, resulting in considerable cost savings as well as a shorter time-to-market for new applications and more efficiently DevOps processes. Another key feature inherent in Otomi as an adoption framework is scalability, as it is easy to expand to new environments. It allows the development of standard profiles easily for new Kubernetes clusters in any cloud.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Security And Compliance\nThanks to guardrails, compliance is an integral part of Otomi, meaning developers and engineers can safely operate containerized workloads on Kubernetes and in observance of compliance regulations. What\u2019s more, organizations don\u2019t spend that much time implementing complex configurations with the risk of technical debt. This especially applies to the operational phase. But it doesn\u2019t stop with a one-off setting of the environment. It is also about keeping all environments up to date in an ongoing and consistent way.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"A Better Understanding Of Costs\nOrganizations quickly lose control of their engineering expenses because they don\u2019t have a clear overview of the technologies being used and their costs. Otomi reduces unexpected and unnecessary expenses.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Standardized For Multi-Tenancy\nIn a multi-tenant architecture, standardizing tenancy allows you to enforce policies to a group of users. It helps you set up different security profiles and provide access to shared tools with users having specific privileges."))),(0,a.kt)("h2",{id:"what-are-the-capabilities-of-an-adoption-framework-for-kubernetes"},"What are the capabilities of an adoption framework for Kubernetes?"),(0,a.kt)("p",null,"The following picture shows all the required capabilities for a Kubernetes adoption framework, which are all incorporated into Otomi:"),(0,a.kt)("p",null,(0,a.kt)("img",{alt:"capabilities",src:n(7089).Z,width:"1788",height:"2326"})))}d.isMDXComponent=!0},7089:(e,t,n)=>{n.d(t,{Z:()=>r});const r=n.p+"assets/images/capabilities-aad63fbe048136bfcc184af026171b32.png"}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2117],{3905:(e,t,n)=>{n.d(t,{Zo:()=>c,kt:()=>f});var r=n(7294);function a(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function o(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function i(e){for(var t=1;t=0||(a[n]=e[n]);return a}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(a[n]=e[n])}return a}var l=r.createContext({}),p=function(e){var t=r.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},c=function(e){var t=p(e.components);return r.createElement(l.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},u=r.forwardRef((function(e,t){var n=e.components,a=e.mdxType,o=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),u=p(n),f=a,m=u["".concat(l,".").concat(f)]||u[f]||d[f]||o;return n?r.createElement(m,i(i({ref:t},c),{},{components:n})):r.createElement(m,i({ref:t},c))}));function f(e,t){var n=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var o=n.length,i=new Array(o);i[0]=u;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:a,i[1]=s;for(var p=2;p{n.r(t),n.d(t,{assets:()=>l,contentTitle:()=>i,default:()=>d,frontMatter:()=>o,metadata:()=>s,toc:()=>p});var r=n(7462),a=(n(7294),n(3905));const o={slug:"adoption-framework",title:"Otomi as adoption framework for Kubernetes",sidebar_label:"Adoption Framework"},i=void 0,s={unversionedId:"use-cases/adoption-framework",id:"use-cases/adoption-framework",title:"Otomi as adoption framework for Kubernetes",description:"What is an adoption framework for Kubernetes?",source:"@site/product/use-cases/adoption-framework.md",sourceDirName:"use-cases",slug:"/use-cases/adoption-framework",permalink:"/product/use-cases/adoption-framework",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/adoption-framework.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"adoption-framework",title:"Otomi as adoption framework for Kubernetes",sidebar_label:"Adoption Framework"},sidebar:"mainSidebar",previous:{title:"Overview",permalink:"/product/use-cases/overview"},next:{title:"Multi-tenancy",permalink:"/product/use-cases/multi-tenancy"}},l={},p=[{value:"What is an adoption framework for Kubernetes?",id:"what-is-an-adoption-framework-for-kubernetes",level:2},{value:"Why use an adoption framework like Otomi for Kubernetes",id:"why-use-an-adoption-framework-like-otomi-for-kubernetes",level:2},{value:"What are the capabilities of an adoption framework for Kubernetes?",id:"what-are-the-capabilities-of-an-adoption-framework-for-kubernetes",level:2}],c={toc:p};function d(e){let{components:t,...o}=e;return(0,a.kt)("wrapper",(0,r.Z)({},c,o,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h2",{id:"what-is-an-adoption-framework-for-kubernetes"},"What is an adoption framework for Kubernetes?"),(0,a.kt)("p",null,"A Kubernetes adoption framework can be used to support migration to Kubernetes in an efficient and streamlined way. The benefit of a Kubernetes adoption framework is that a number of required capabilities and configurations are established initially, which determine how containerized applications are going to be deployed, secured and operated. A Kubernetes adoption framework provides all the required controls following best practices in the areas of security, compliance, observability, CD, networking and self-service. All based on Infrastructure as Code."),(0,a.kt)("p",null,"A Kubernetes adoption framework is implemented differently for each organization. Each company has different requirements, has to meet different compliance requirements, and uses different cloud infrastructures. Creating a multi-/hybrid cloud Kubernetes landing zone requires a significant investment. Otomi can be used as a Kubernetes adoption framework to create a landing zone for containerized applications on any Kubernetes cluster in any cloud and can be tailored based on organization specific requirements."),(0,a.kt)("h2",{id:"why-use-an-adoption-framework-like-otomi-for-kubernetes"},"Why use an adoption framework like Otomi for Kubernetes"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Compliant With Security Regulations\nGiven that established parameters apply, developers operate within well-defined boundaries. This means that companies do not risk of running containerized workloads that differ from their compliance policy. Similarly, the IT manager is less concerned about compliance as it is embedded in the foundation of the IT infrastructure.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Speed \u200b\u200bAnd Scalability\nAs mentioned above, a migration to Kubernetes can happen more quickly with the help of an adoption framework. Preparation time is significantly reduced. Creating a compliant landigzone for Kubernetes can take up to 12 months (or even more) of work (if you have the required knowledge onboard). This time can be cut down to days with the use of Otomi, resulting in considerable cost savings as well as a shorter time-to-market for new applications and more efficiently DevOps processes. Another key feature inherent in Otomi as an adoption framework is scalability, as it is easy to expand to new environments. It allows the development of standard profiles easily for new Kubernetes clusters in any cloud.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Security And Compliance\nThanks to guardrails, compliance is an integral part of Otomi, meaning developers and engineers can safely operate containerized workloads on Kubernetes and in observance of compliance regulations. What\u2019s more, organizations don\u2019t spend that much time implementing complex configurations with the risk of technical debt. This especially applies to the operational phase. But it doesn\u2019t stop with a one-off setting of the environment. It is also about keeping all environments up to date in an ongoing and consistent way.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"A Better Understanding Of Costs\nOrganizations quickly lose control of their engineering expenses because they don\u2019t have a clear overview of the technologies being used and their costs. Otomi reduces unexpected and unnecessary expenses.")),(0,a.kt)("li",{parentName:"ol"},(0,a.kt)("p",{parentName:"li"},"Standardized For Multi-Tenancy\nIn a multi-tenant architecture, standardizing tenancy allows you to enforce policies to a group of users. It helps you set up different security profiles and provide access to shared tools with users having specific privileges."))),(0,a.kt)("h2",{id:"what-are-the-capabilities-of-an-adoption-framework-for-kubernetes"},"What are the capabilities of an adoption framework for Kubernetes?"),(0,a.kt)("p",null,"The following picture shows all the required capabilities for a Kubernetes adoption framework, which are all incorporated into Otomi:"),(0,a.kt)("p",null,(0,a.kt)("img",{alt:"capabilities",src:n(7089).Z,width:"1788",height:"2326"})))}d.isMDXComponent=!0},7089:(e,t,n)=>{n.d(t,{Z:()=>r});const r=n.p+"assets/images/capabilities-aad63fbe048136bfcc184af026171b32.png"}}]); \ No newline at end of file diff --git a/assets/js/4f01d7c7.83164f21.js b/assets/js/4f01d7c7.f12f572f.js similarity index 99% rename from assets/js/4f01d7c7.83164f21.js rename to assets/js/4f01d7c7.f12f572f.js index 89973f131..6de0855fb 100644 --- a/assets/js/4f01d7c7.83164f21.js +++ b/assets/js/4f01d7c7.f12f572f.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[7015],{3905:(e,t,o)=>{o.d(t,{Zo:()=>d,kt:()=>m});var n=o(7294);function a(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function r(e){for(var t=1;t=0||(a[o]=e[o]);return a}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(a[o]=e[o])}return a}var l=n.createContext({}),u=function(e){var t=n.useContext(l),o=t;return e&&(o="function"==typeof e?e(t):r(r({},t),e)),o},d=function(e){var t=u(e.components);return n.createElement(l.Provider,{value:t},e.children)},c={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var o=e.components,a=e.mdxType,i=e.originalType,l=e.parentName,d=s(e,["components","mdxType","originalType","parentName"]),p=u(o),m=a,h=p["".concat(l,".").concat(m)]||p[m]||c[m]||i;return o?n.createElement(h,r(r({ref:t},d),{},{components:o})):n.createElement(h,r({ref:t},d))}));function m(e,t){var o=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var i=o.length,r=new Array(i);r[0]=p;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:a,r[1]=s;for(var u=2;u{o.r(t),o.d(t,{assets:()=>l,contentTitle:()=>r,default:()=>c,frontMatter:()=>i,metadata:()=>s,toc:()=>u});var n=o(7462),a=(o(7294),o(3905));const i={slug:"introduction",title:"Why Otomi",sidebar_label:"Why Otomi"},r=void 0,s={unversionedId:"introduction",id:"introduction",title:"Why Otomi",description:"The vision",source:"@site/product/introduction.md",sourceDirName:".",slug:"/introduction",permalink:"/product/introduction",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/introduction.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"introduction",title:"Why Otomi",sidebar_label:"Why Otomi"},sidebar:"mainSidebar",next:{title:"Otomi Projects",permalink:"/product/architecture"}},l={},u=[{value:"The vision",id:"the-vision",level:2},{value:"What is Otomi?",id:"what-is-otomi",level:2},{value:"What is the difference between an IDP and a PaaS?",id:"what-is-the-difference-between-an-idp-and-a-paas",level:3},{value:"When to build an IDP or use a PaaS?",id:"when-to-build-an-idp-or-use-a-paas",level:3},{value:"Otomi for developers",id:"otomi-for-developers",level:2},{value:"Removing the complexity",id:"removing-the-complexity",level:3},{value:"All the tools you need",id:"all-the-tools-you-need",level:3},{value:"Best practices",id:"best-practices",level:3},{value:"Self-Serving",id:"self-serving",level:3},{value:"Otomi for Platform Teams",id:"otomi-for-platform-teams",level:2},{value:"Avoid Cloud Lock-In",id:"avoid-cloud-lock-in",level:3},{value:"Make Developers Self Serving",id:"make-developers-self-serving",level:3},{value:"Lower The Operational Burden",id:"lower-the-operational-burden",level:3},{value:"Prevent Kubernetes Cluster Sprawl",id:"prevent-kubernetes-cluster-sprawl",level:3}],d={toc:u};function c(e){let{components:t,...o}=e;return(0,a.kt)("wrapper",(0,n.Z)({},d,o,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h2",{id:"the-vision"},"The vision"),(0,a.kt)("p",null,"Kubernetes has been called The Operating System of the Cloud. In our opinion, Kubernetes is only the Kernel of the Operating System of the Cloud. The Operating System (or Kubernetes-based Platform) is something you'll need to build yourself. And this is what organizations are now doing when using Kubernetes. All reinventing the wheel."),(0,a.kt)("p",null,"Building a Kubernetes-based platform requires a huge investment and requires skilled engineers. But why would you invest in building and maintaining a custom platform? Why can't you just install everyting you need to turn Kubernetes into a full platform, just like you can download a Linux distribution? "),(0,a.kt)("p",null,"This is what we indended when we created Otomi. Any infrastructure, any K8s, one install, all the tools you need in an integrated and automated way, easy self-service and everything as code."),(0,a.kt)("h2",{id:"what-is-otomi"},"What is Otomi?"),(0,a.kt)("p",null,"Otomi is a self-hosted PaaS and adds developer- and operations-centric tools, automation and self-service on top of Kubernetes offering a multi and hybrid platform experience out-of-the-box. Otomi is placed in the CNCF landscape under the ",(0,a.kt)("a",{parentName:"p",href:"https://landscape.cncf.io/guide#platform--paas-container-service"},"PaaS/Container Service")," section. Otomi attempts to connect many of the technologies found in the CNCF landscape in a way to provide direct value. No more re-inventing the wheel when building and maintaining your own Kubernetes based platform or bespoke stack."),(0,a.kt)("h3",{id:"what-is-the-difference-between-an-idp-and-a-paas"},"What is the difference between an IDP and a PaaS?"),(0,a.kt)("p",null,"An Internal Developer Platform (IDP) consists of many different technologies, glued together to lowers cognitive load on developers without abstracting away context and underlying technologies. An IDP is always custom built."),(0,a.kt)("p",null,"A PaaS for Kubernetes also lowers cognitive load on developers, but abstracts away most of the underlying technologies. Unlike an IDP, a PaaS can be used almost instantly, just like downloading and using your favourite Linux Distribution. Organizations that use a PaaS instead of building an IDP can enjoy lower upfront costs and huge time savings."),(0,a.kt)("h3",{id:"when-to-build-an-idp-or-use-a-paas"},"When to build an IDP or use a PaaS?"),(0,a.kt)("p",null,"Because building an IDP requires a large upfront investment, it\u2019s mostly suitable for large enterprises. For smaller organizations a PaaS can sometimes be far more efficient than building a custom IDP in-house."),(0,a.kt)("h2",{id:"otomi-for-developers"},"Otomi for developers"),(0,a.kt)("p",null,"Otomi let's developers focus on their application, not on writing Kubernetes manifests! Kubernetes is great for running containers, but it's complex. Wouldn't it be awesome if you didn't need to worry about understanding Kubernetes objects and writing YAML manifests?"),(0,a.kt)("p",null,"This is how Otomi helps developers:"),(0,a.kt)("h3",{id:"removing-the-complexity"},"Removing the complexity"),(0,a.kt)("p",null,"As a Developer, you want to focus on your code and don\u2019t be bothered with Kubernetes internals. With Otomi, you can deploy your apps on Kubernetes without needing to understand or learn Kubernetes. Just build your image, push it to a registry in Otomi and use the Web Console to deploy your app in just a couple of minutes. Otomi makes Kubernetes easy!"),(0,a.kt)("h3",{id:"all-the-tools-you-need"},"All the tools you need"),(0,a.kt)("p",null,"Otomi provides developers with all the tools they need. After deploying your app you can directly see all the container logs, metrics, status, policy violations and vulnerabilities. Next to access to al kinds of dashboards, you will also get access to Harbor, Tekton and Argo CD. "),(0,a.kt)("h3",{id:"best-practices"},"Best practices"),(0,a.kt)("p",null,"Otomi offers you the ability to immediately start deploying applications on Kubernetes and configure public exposure. This will give you a jump start to get apps running on Kubernetes. But in time you will probably learn more about Kubernetes and start trying out things yourself. Otomi does not force you to use the Web Console. You can just as easily download the KubeConfig for your team and create and deploy manifests yourself. But Otomi will always force you to adhere to the configured safeguards and best practices."),(0,a.kt)("h3",{id:"self-serving"},"Self-Serving"),(0,a.kt)("p",null,"As a developer, you don\u2019t like to go to the Ops team asking for help. Otomi provides full developer self-service. Developers can spin up new virtual environments, download pull secrets, create Kubernetes secrets, build images from source code, deploy workloads and configure public exposure. And all of these features are accessible through just one Web Console. Now you can deliver code completely autonomously."),(0,a.kt)("h2",{id:"otomi-for-platform-teams"},"Otomi for Platform Teams"),(0,a.kt)("p",null,"If you can\u2019t scale beyond a handful of teams you're going to lose speed. Speed is everything to bring new products and applications to market. No one wants to slow down developers. Empower developers, ensure quality, compliance, and governance, avoid lock-in, and lower the operational burden. These are some of the challenges platform teams have to deal with and where Otomi can help out."),(0,a.kt)("h3",{id:"avoid-cloud-lock-in"},"Avoid Cloud Lock-In"),(0,a.kt)("p",null,"Are you worried that you can\u2019t adopt cloud-native technology without becoming completely reliant on one cloud provider? One way that organizations outsource management for Kubernetes is to use one of the cloud provider\u2019s Kubernetes versions in conjunction with a variety of cloud provider native services. This is often faster than using vanilla Kubernetes and managing integrations and infrastructure in-house, but it also completely locks the organization into the cloud provider and often becomes very expensive."),(0,a.kt)("p",null,"This approach also takes away the flexibility to change cloud providers in the future while increasing the financial risks. With Otomi, you don\u2019t have to lock yourself into any cloud provider or risk rapidly increasing cloud service bills in order to get the fastest possible platform to deploy containerized applications."),(0,a.kt)("h3",{id:"make-developers-self-serving"},"Make Developers Self Serving"),(0,a.kt)("p",null,"Free developers from worrying about the underlying platform setup while still enforcing standards and best practices so they can focus on delivering code. With Otomi, developers can be fully self-serving. They can spin up new namespaces, get access to all the tools they need, build images from source code, create secrets, deploy workloads, configure public exposure, add service monitors, and much more. And all of these features are accessible through just one web UI."),(0,a.kt)("p",null,"Platform administrators have access to all the platform applications. Team administrators can create team spaces for development teams and team members can create multiple namespaces within their team space(s)."),(0,a.kt)("h3",{id:"lower-the-operational-burden"},"Lower The Operational Burden"),(0,a.kt)("p",null,"Choosing the DIY platform engineering approach can be time-consuming and complex. On average, Platform teams need at least 6 months to build an initial setup. And the ongoing maintenance and hardening afterwards can become an operational nightmare. Otomi helps Platform teams to lower the operational burden by taking over the application management of everything running on top of Kubernetes, including the lifecycle management of all the integrated K8s applications."),(0,a.kt)("p",null,"This enables platform teams to focus on another very important aspect: Kubernetes cluster infrastructure management and cloud security. Now you have time to focus on other important aspects instead of building a custom (internal) developer platform solution."),(0,a.kt)("h3",{id:"prevent-kubernetes-cluster-sprawl"},"Prevent Kubernetes Cluster Sprawl"),(0,a.kt)("p",null,"As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work."),(0,a.kt)("p",null,"With Otomi you can support (soft) multi-tenancy, allowing multiple development teams to work independently of each other on the same cluster, while sharing all the tools. Now you only have to deploy a single dev or staging cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl."))}c.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[7015],{3905:(e,t,o)=>{o.d(t,{Zo:()=>d,kt:()=>m});var n=o(7294);function a(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function r(e){for(var t=1;t=0||(a[o]=e[o]);return a}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(a[o]=e[o])}return a}var l=n.createContext({}),u=function(e){var t=n.useContext(l),o=t;return e&&(o="function"==typeof e?e(t):r(r({},t),e)),o},d=function(e){var t=u(e.components);return n.createElement(l.Provider,{value:t},e.children)},c={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var o=e.components,a=e.mdxType,i=e.originalType,l=e.parentName,d=s(e,["components","mdxType","originalType","parentName"]),p=u(o),m=a,h=p["".concat(l,".").concat(m)]||p[m]||c[m]||i;return o?n.createElement(h,r(r({ref:t},d),{},{components:o})):n.createElement(h,r({ref:t},d))}));function m(e,t){var o=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var i=o.length,r=new Array(i);r[0]=p;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:a,r[1]=s;for(var u=2;u{o.r(t),o.d(t,{assets:()=>l,contentTitle:()=>r,default:()=>c,frontMatter:()=>i,metadata:()=>s,toc:()=>u});var n=o(7462),a=(o(7294),o(3905));const i={slug:"introduction",title:"Why Otomi",sidebar_label:"Why Otomi"},r=void 0,s={unversionedId:"introduction",id:"introduction",title:"Why Otomi",description:"The vision",source:"@site/product/introduction.md",sourceDirName:".",slug:"/introduction",permalink:"/product/introduction",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/introduction.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"introduction",title:"Why Otomi",sidebar_label:"Why Otomi"},sidebar:"mainSidebar",next:{title:"Otomi Projects",permalink:"/product/architecture"}},l={},u=[{value:"The vision",id:"the-vision",level:2},{value:"What is Otomi?",id:"what-is-otomi",level:2},{value:"What is the difference between an IDP and a PaaS?",id:"what-is-the-difference-between-an-idp-and-a-paas",level:3},{value:"When to build an IDP or use a PaaS?",id:"when-to-build-an-idp-or-use-a-paas",level:3},{value:"Otomi for developers",id:"otomi-for-developers",level:2},{value:"Removing the complexity",id:"removing-the-complexity",level:3},{value:"All the tools you need",id:"all-the-tools-you-need",level:3},{value:"Best practices",id:"best-practices",level:3},{value:"Self-Serving",id:"self-serving",level:3},{value:"Otomi for Platform Teams",id:"otomi-for-platform-teams",level:2},{value:"Avoid Cloud Lock-In",id:"avoid-cloud-lock-in",level:3},{value:"Make Developers Self Serving",id:"make-developers-self-serving",level:3},{value:"Lower The Operational Burden",id:"lower-the-operational-burden",level:3},{value:"Prevent Kubernetes Cluster Sprawl",id:"prevent-kubernetes-cluster-sprawl",level:3}],d={toc:u};function c(e){let{components:t,...o}=e;return(0,a.kt)("wrapper",(0,n.Z)({},d,o,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h2",{id:"the-vision"},"The vision"),(0,a.kt)("p",null,"Kubernetes has been called The Operating System of the Cloud. In our opinion, Kubernetes is only the Kernel of the Operating System of the Cloud. The Operating System (or Kubernetes-based Platform) is something you'll need to build yourself. And this is what organizations are now doing when using Kubernetes. All reinventing the wheel."),(0,a.kt)("p",null,"Building a Kubernetes-based platform requires a huge investment and requires skilled engineers. But why would you invest in building and maintaining a custom platform? Why can't you just install everyting you need to turn Kubernetes into a full platform, just like you can download a Linux distribution? "),(0,a.kt)("p",null,"This is what we indended when we created Otomi. Any infrastructure, any K8s, one install, all the tools you need in an integrated and automated way, easy self-service and everything as code."),(0,a.kt)("h2",{id:"what-is-otomi"},"What is Otomi?"),(0,a.kt)("p",null,"Otomi is a self-hosted PaaS and adds developer- and operations-centric tools, automation and self-service on top of Kubernetes offering a multi and hybrid platform experience out-of-the-box. Otomi is placed in the CNCF landscape under the ",(0,a.kt)("a",{parentName:"p",href:"https://landscape.cncf.io/guide#platform--paas-container-service"},"PaaS/Container Service")," section. Otomi attempts to connect many of the technologies found in the CNCF landscape in a way to provide direct value. No more re-inventing the wheel when building and maintaining your own Kubernetes based platform or bespoke stack."),(0,a.kt)("h3",{id:"what-is-the-difference-between-an-idp-and-a-paas"},"What is the difference between an IDP and a PaaS?"),(0,a.kt)("p",null,"An Internal Developer Platform (IDP) consists of many different technologies, glued together to lowers cognitive load on developers without abstracting away context and underlying technologies. An IDP is always custom built."),(0,a.kt)("p",null,"A PaaS for Kubernetes also lowers cognitive load on developers, but abstracts away most of the underlying technologies. Unlike an IDP, a PaaS can be used almost instantly, just like downloading and using your favourite Linux Distribution. Organizations that use a PaaS instead of building an IDP can enjoy lower upfront costs and huge time savings."),(0,a.kt)("h3",{id:"when-to-build-an-idp-or-use-a-paas"},"When to build an IDP or use a PaaS?"),(0,a.kt)("p",null,"Because building an IDP requires a large upfront investment, it\u2019s mostly suitable for large enterprises. For smaller organizations a PaaS can sometimes be far more efficient than building a custom IDP in-house."),(0,a.kt)("h2",{id:"otomi-for-developers"},"Otomi for developers"),(0,a.kt)("p",null,"Otomi let's developers focus on their application, not on writing Kubernetes manifests! Kubernetes is great for running containers, but it's complex. Wouldn't it be awesome if you didn't need to worry about understanding Kubernetes objects and writing YAML manifests?"),(0,a.kt)("p",null,"This is how Otomi helps developers:"),(0,a.kt)("h3",{id:"removing-the-complexity"},"Removing the complexity"),(0,a.kt)("p",null,"As a Developer, you want to focus on your code and don\u2019t be bothered with Kubernetes internals. With Otomi, you can deploy your apps on Kubernetes without needing to understand or learn Kubernetes. Just build your image, push it to a registry in Otomi and use the Web Console to deploy your app in just a couple of minutes. Otomi makes Kubernetes easy!"),(0,a.kt)("h3",{id:"all-the-tools-you-need"},"All the tools you need"),(0,a.kt)("p",null,"Otomi provides developers with all the tools they need. After deploying your app you can directly see all the container logs, metrics, status, policy violations and vulnerabilities. Next to access to al kinds of dashboards, you will also get access to Harbor, Tekton and Argo CD. "),(0,a.kt)("h3",{id:"best-practices"},"Best practices"),(0,a.kt)("p",null,"Otomi offers you the ability to immediately start deploying applications on Kubernetes and configure public exposure. This will give you a jump start to get apps running on Kubernetes. But in time you will probably learn more about Kubernetes and start trying out things yourself. Otomi does not force you to use the Web Console. You can just as easily download the KubeConfig for your team and create and deploy manifests yourself. But Otomi will always force you to adhere to the configured safeguards and best practices."),(0,a.kt)("h3",{id:"self-serving"},"Self-Serving"),(0,a.kt)("p",null,"As a developer, you don\u2019t like to go to the Ops team asking for help. Otomi provides full developer self-service. Developers can spin up new virtual environments, download pull secrets, create Kubernetes secrets, build images from source code, deploy workloads and configure public exposure. And all of these features are accessible through just one Web Console. Now you can deliver code completely autonomously."),(0,a.kt)("h2",{id:"otomi-for-platform-teams"},"Otomi for Platform Teams"),(0,a.kt)("p",null,"If you can\u2019t scale beyond a handful of teams you're going to lose speed. Speed is everything to bring new products and applications to market. No one wants to slow down developers. Empower developers, ensure quality, compliance, and governance, avoid lock-in, and lower the operational burden. These are some of the challenges platform teams have to deal with and where Otomi can help out."),(0,a.kt)("h3",{id:"avoid-cloud-lock-in"},"Avoid Cloud Lock-In"),(0,a.kt)("p",null,"Are you worried that you can\u2019t adopt cloud-native technology without becoming completely reliant on one cloud provider? One way that organizations outsource management for Kubernetes is to use one of the cloud provider\u2019s Kubernetes versions in conjunction with a variety of cloud provider native services. This is often faster than using vanilla Kubernetes and managing integrations and infrastructure in-house, but it also completely locks the organization into the cloud provider and often becomes very expensive."),(0,a.kt)("p",null,"This approach also takes away the flexibility to change cloud providers in the future while increasing the financial risks. With Otomi, you don\u2019t have to lock yourself into any cloud provider or risk rapidly increasing cloud service bills in order to get the fastest possible platform to deploy containerized applications."),(0,a.kt)("h3",{id:"make-developers-self-serving"},"Make Developers Self Serving"),(0,a.kt)("p",null,"Free developers from worrying about the underlying platform setup while still enforcing standards and best practices so they can focus on delivering code. With Otomi, developers can be fully self-serving. They can spin up new namespaces, get access to all the tools they need, build images from source code, create secrets, deploy workloads, configure public exposure, add service monitors, and much more. And all of these features are accessible through just one web UI."),(0,a.kt)("p",null,"Platform administrators have access to all the platform applications. Team administrators can create team spaces for development teams and team members can create multiple namespaces within their team space(s)."),(0,a.kt)("h3",{id:"lower-the-operational-burden"},"Lower The Operational Burden"),(0,a.kt)("p",null,"Choosing the DIY platform engineering approach can be time-consuming and complex. On average, Platform teams need at least 6 months to build an initial setup. And the ongoing maintenance and hardening afterwards can become an operational nightmare. Otomi helps Platform teams to lower the operational burden by taking over the application management of everything running on top of Kubernetes, including the lifecycle management of all the integrated K8s applications."),(0,a.kt)("p",null,"This enables platform teams to focus on another very important aspect: Kubernetes cluster infrastructure management and cloud security. Now you have time to focus on other important aspects instead of building a custom (internal) developer platform solution."),(0,a.kt)("h3",{id:"prevent-kubernetes-cluster-sprawl"},"Prevent Kubernetes Cluster Sprawl"),(0,a.kt)("p",null,"As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work."),(0,a.kt)("p",null,"With Otomi you can support (soft) multi-tenancy, allowing multiple development teams to work independently of each other on the same cluster, while sharing all the tools. Now you only have to deploy a single dev or staging cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl."))}c.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/5db37859.9f73e243.js b/assets/js/5db37859.9b4fc439.js similarity index 98% rename from assets/js/5db37859.9f73e243.js rename to assets/js/5db37859.9b4fc439.js index 80dee9a71..7276efab4 100644 --- a/assets/js/5db37859.9f73e243.js +++ b/assets/js/5db37859.9b4fc439.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[344],{3905:(e,t,o)=>{o.d(t,{Zo:()=>u,kt:()=>d});var n=o(7294);function r(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function a(e){for(var t=1;t=0||(r[o]=e[o]);return r}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(r[o]=e[o])}return r}var s=n.createContext({}),l=function(e){var t=n.useContext(s),o=t;return e&&(o="function"==typeof e?e(t):a(a({},t),e)),o},u=function(e){var t=l(e.components);return n.createElement(s.Provider,{value:t},e.children)},m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var o=e.components,r=e.mdxType,i=e.originalType,s=e.parentName,u=c(e,["components","mdxType","originalType","parentName"]),p=l(o),d=r,f=p["".concat(s,".").concat(d)]||p[d]||m[d]||i;return o?n.createElement(f,a(a({ref:t},u),{},{components:o})):n.createElement(f,a({ref:t},u))}));function d(e,t){var o=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var i=o.length,a=new Array(i);a[0]=p;var c={};for(var s in t)hasOwnProperty.call(t,s)&&(c[s]=t[s]);c.originalType=e,c.mdxType="string"==typeof e?e:r,a[1]=c;for(var l=2;l{o.r(t),o.d(t,{assets:()=>s,contentTitle:()=>a,default:()=>m,frontMatter:()=>i,metadata:()=>c,toc:()=>l});var n=o(7462),r=(o(7294),o(3905));const i={title:"Contribution Expectations",slug:"expectations",sidebar_label:"Expectations"},a=void 0,c={unversionedId:"expectations",id:"expectations",title:"Contribution Expectations",description:"Otomi is a community project.",source:"@site/community/expectations.md",sourceDirName:".",slug:"/expectations",permalink:"/community/expectations",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/expectations.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{title:"Contribution Expectations",slug:"expectations",sidebar_label:"Expectations"},sidebar:"mainSidebar",previous:{title:"Code of Conduct",permalink:"/community/code-of-conduct"}},s={},l=[{value:"Code review",id:"code-review",level:2},{value:"Expectations of reviewers",id:"expectations-of-reviewers",level:2},{value:"Review comments",id:"review-comments",level:3},{value:"Review latency",id:"review-latency",level:3},{value:"Thank you",id:"thank-you",level:2}],u={toc:l};function m(e){let{components:t,...o}=e;return(0,r.kt)("wrapper",(0,n.Z)({},u,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"Otomi is a community project.\nConsequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment."),(0,r.kt)("p",null,"The first and foremost goal of the Otomi community is to develop a stack of configurable k8s applications that work in tandem, in order to give k8s users control over their distributed applications."),(0,r.kt)("p",null,"We therefore describe the expectations for members of the Otomi community.\nThis document is intended to be a living one that evolves as the community evolves via the same PR and code review process that shapes the rest of the project.\nIt currently covers the expectations of conduct that govern all members of the community as well as the expectations around code review that govern all active contributors to Otomi."),(0,r.kt)("h2",{id:"code-review"},"Code review"),(0,r.kt)("p",null,"As a community we believe in the value of code review for all contributions.\nCode review increases both the quality and readability of our codebase, which\nin turn produces high quality software."),(0,r.kt)("p",null,"Consequently, as a community we expect that all active participants in the community will also be active reviewers."),(0,r.kt)("h2",{id:"expectations-of-reviewers"},"Expectations of reviewers"),(0,r.kt)("h3",{id:"review-comments"},"Review comments"),(0,r.kt)("p",null,"Because reviewers are often the first points of contact between new members of the community and can significantly impact the first impression of the Otomi community, reviewers are especially important in shaping the Otomi community. Reviewers are highly encouraged to not only abide by the ",(0,r.kt)("a",{parentName:"p",href:"/community/code-of-conduct"},"code of conduct")," but are strongly encouraged to go above and beyond the code of conduct to promote a collaborative, respectful Otomi community."),(0,r.kt)("h3",{id:"review-latency"},"Review latency"),(0,r.kt)("p",null,"Reviewers are expected to respond in a timely fashion to PRs that are assigned to them. Reviewers are expected to respond to an ",(0,r.kt)("em",{parentName:"p"},"active")," PRs with reasonable latency, and if reviewers fail to respond, those PRs may be assigned to other reviewers."),(0,r.kt)("h2",{id:"thank-you"},"Thank you"),(0,r.kt)("p",null,"We want to thank everyone who contributes their time and effort to making Otomi both a successful endeavour as well as a successful community. The strength of our software lies in the combined strengths of each individual community member. Thanks!"))}m.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[344],{3905:(e,t,o)=>{o.d(t,{Zo:()=>u,kt:()=>d});var n=o(7294);function r(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function a(e){for(var t=1;t=0||(r[o]=e[o]);return r}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(r[o]=e[o])}return r}var s=n.createContext({}),l=function(e){var t=n.useContext(s),o=t;return e&&(o="function"==typeof e?e(t):a(a({},t),e)),o},u=function(e){var t=l(e.components);return n.createElement(s.Provider,{value:t},e.children)},m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var o=e.components,r=e.mdxType,i=e.originalType,s=e.parentName,u=c(e,["components","mdxType","originalType","parentName"]),p=l(o),d=r,f=p["".concat(s,".").concat(d)]||p[d]||m[d]||i;return o?n.createElement(f,a(a({ref:t},u),{},{components:o})):n.createElement(f,a({ref:t},u))}));function d(e,t){var o=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var i=o.length,a=new Array(i);a[0]=p;var c={};for(var s in t)hasOwnProperty.call(t,s)&&(c[s]=t[s]);c.originalType=e,c.mdxType="string"==typeof e?e:r,a[1]=c;for(var l=2;l{o.r(t),o.d(t,{assets:()=>s,contentTitle:()=>a,default:()=>m,frontMatter:()=>i,metadata:()=>c,toc:()=>l});var n=o(7462),r=(o(7294),o(3905));const i={title:"Contribution Expectations",slug:"expectations",sidebar_label:"Expectations"},a=void 0,c={unversionedId:"expectations",id:"expectations",title:"Contribution Expectations",description:"Otomi is a community project.",source:"@site/community/expectations.md",sourceDirName:".",slug:"/expectations",permalink:"/community/expectations",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/expectations.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{title:"Contribution Expectations",slug:"expectations",sidebar_label:"Expectations"},sidebar:"mainSidebar",previous:{title:"Code of Conduct",permalink:"/community/code-of-conduct"}},s={},l=[{value:"Code review",id:"code-review",level:2},{value:"Expectations of reviewers",id:"expectations-of-reviewers",level:2},{value:"Review comments",id:"review-comments",level:3},{value:"Review latency",id:"review-latency",level:3},{value:"Thank you",id:"thank-you",level:2}],u={toc:l};function m(e){let{components:t,...o}=e;return(0,r.kt)("wrapper",(0,n.Z)({},u,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"Otomi is a community project.\nConsequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment."),(0,r.kt)("p",null,"The first and foremost goal of the Otomi community is to develop a stack of configurable k8s applications that work in tandem, in order to give k8s users control over their distributed applications."),(0,r.kt)("p",null,"We therefore describe the expectations for members of the Otomi community.\nThis document is intended to be a living one that evolves as the community evolves via the same PR and code review process that shapes the rest of the project.\nIt currently covers the expectations of conduct that govern all members of the community as well as the expectations around code review that govern all active contributors to Otomi."),(0,r.kt)("h2",{id:"code-review"},"Code review"),(0,r.kt)("p",null,"As a community we believe in the value of code review for all contributions.\nCode review increases both the quality and readability of our codebase, which\nin turn produces high quality software."),(0,r.kt)("p",null,"Consequently, as a community we expect that all active participants in the community will also be active reviewers."),(0,r.kt)("h2",{id:"expectations-of-reviewers"},"Expectations of reviewers"),(0,r.kt)("h3",{id:"review-comments"},"Review comments"),(0,r.kt)("p",null,"Because reviewers are often the first points of contact between new members of the community and can significantly impact the first impression of the Otomi community, reviewers are especially important in shaping the Otomi community. Reviewers are highly encouraged to not only abide by the ",(0,r.kt)("a",{parentName:"p",href:"/community/code-of-conduct"},"code of conduct")," but are strongly encouraged to go above and beyond the code of conduct to promote a collaborative, respectful Otomi community."),(0,r.kt)("h3",{id:"review-latency"},"Review latency"),(0,r.kt)("p",null,"Reviewers are expected to respond in a timely fashion to PRs that are assigned to them. Reviewers are expected to respond to an ",(0,r.kt)("em",{parentName:"p"},"active")," PRs with reasonable latency, and if reviewers fail to respond, those PRs may be assigned to other reviewers."),(0,r.kt)("h2",{id:"thank-you"},"Thank you"),(0,r.kt)("p",null,"We want to thank everyone who contributes their time and effort to making Otomi both a successful endeavour as well as a successful community. The strength of our software lies in the combined strengths of each individual community member. Thanks!"))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/70b0dc77.fde1e8cb.js b/assets/js/70b0dc77.869b8552.js similarity index 98% rename from assets/js/70b0dc77.fde1e8cb.js rename to assets/js/70b0dc77.869b8552.js index 3a232a684..4637df077 100644 --- a/assets/js/70b0dc77.fde1e8cb.js +++ b/assets/js/70b0dc77.869b8552.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2515],{3905:(e,t,n)=>{n.d(t,{Zo:()=>c,kt:()=>g});var r=n(7294);function o(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function i(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function s(e){for(var t=1;t=0||(o[n]=e[n]);return o}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(o[n]=e[n])}return o}var l=r.createContext({}),u=function(e){var t=r.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):s(s({},t),e)),n},c=function(e){var t=u(e.components);return r.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},d=r.forwardRef((function(e,t){var n=e.components,o=e.mdxType,i=e.originalType,l=e.parentName,c=a(e,["components","mdxType","originalType","parentName"]),d=u(n),g=o,f=d["".concat(l,".").concat(g)]||d[g]||p[g]||i;return n?r.createElement(f,s(s({ref:t},c),{},{components:n})):r.createElement(f,s({ref:t},c))}));function g(e,t){var n=arguments,o=t&&t.mdxType;if("string"==typeof e||o){var i=n.length,s=new Array(i);s[0]=d;var a={};for(var l in t)hasOwnProperty.call(t,l)&&(a[l]=t[l]);a.originalType=e,a.mdxType="string"==typeof e?e:o,s[1]=a;for(var u=2;u{n.r(t),n.d(t,{assets:()=>l,contentTitle:()=>s,default:()=>p,frontMatter:()=>i,metadata:()=>a,toc:()=>u});var r=n(7462),o=(n(7294),n(3905));const i={slug:"edge",title:"Otomi at the edge",sidebar_label:"Edge"},s=void 0,a={unversionedId:"use-cases/edge",id:"use-cases/edge",title:"Otomi at the edge",description:"Introduction",source:"@site/product/use-cases/edge.md",sourceDirName:"use-cases",slug:"/use-cases/edge",permalink:"/product/use-cases/edge",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/edge.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"edge",title:"Otomi at the edge",sidebar_label:"Edge"}},l={},u=[{value:"Introduction",id:"introduction",level:2},{value:"How Otomi supports edge computing using Kubernetes",id:"how-otomi-supports-edge-computing-using-kubernetes",level:2}],c={toc:u};function p(e){let{components:t,...i}=e;return(0,o.kt)("wrapper",(0,r.Z)({},c,i,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h2",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,"Edge computing is an approach where you run applications as close as possible to its data sources or end users. One of the benefits is improved response times. "),(0,o.kt)("p",null,"However, managing edge applications using Kubernetes comes with challenges, like:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Deploy and update applications consistently accross multiple clusters"),(0,o.kt)("li",{parentName:"ul"},"Manage the run-time specifications for the applications like ingress, certificates, DNS, network policies, etc."),(0,o.kt)("li",{parentName:"ul"},"Lifecycle management of all supporting tools"),(0,o.kt)("li",{parentName:"ul"},"Using managed Kubernetes services in different clouds/infrastructures")),(0,o.kt)("h2",{id:"how-otomi-supports-edge-computing-using-kubernetes"},"How Otomi supports edge computing using Kubernetes"),(0,o.kt)("p",null,"One of the benefits of Otomi is that everything managed by Otomi can be specified in a single values file. This enables you to not only define the applications workloads that need to be running on the cluster, but also all the required tools and configuration to support and secure the workloads."),(0,o.kt)("p",null,"Let's explain this with an example:"),(0,o.kt)("p",null,"Suppose you have 2 application workloads that you would like to run on multiple Kubernetes clusters in multiple geographic regions, using different public cloud providers (AWS, Azure, GCP) and different Kubernetes versions (1.22 and 1.23). Next to the 2 workloads, you also would like to use Istio for mTLS, cert-manager for certificates, ingress/egress network policies for isolation and HTTP response headers. Because you can not afford using L7 load balancers with WAF features in the different clouds, you would like to implement Nginx ingress with Modsecurity and OWASP filtering. The following picture shows the desired situation:"),(0,o.kt)("p",null,(0,o.kt)("img",{alt:"edge",src:n(2300).Z,width:"1496",height:"1398"})),(0,o.kt)("p",null,"Read ",(0,o.kt)("a",{parentName:"p",href:"/docs/for-ops/how-to/core-only"},"this")," how-to to learn more about installing Otomi at the edge."))}p.isMDXComponent=!0},2300:(e,t,n)=>{n.d(t,{Z:()=>r});const r=n.p+"assets/images/edge-173d01e1fe3f7ac45484237e916968e3.png"}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2515],{3905:(e,t,n)=>{n.d(t,{Zo:()=>c,kt:()=>g});var r=n(7294);function o(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function i(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);t&&(r=r.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,r)}return n}function s(e){for(var t=1;t=0||(o[n]=e[n]);return o}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(r=0;r=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(o[n]=e[n])}return o}var l=r.createContext({}),u=function(e){var t=r.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):s(s({},t),e)),n},c=function(e){var t=u(e.components);return r.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return r.createElement(r.Fragment,{},t)}},d=r.forwardRef((function(e,t){var n=e.components,o=e.mdxType,i=e.originalType,l=e.parentName,c=a(e,["components","mdxType","originalType","parentName"]),d=u(n),g=o,f=d["".concat(l,".").concat(g)]||d[g]||p[g]||i;return n?r.createElement(f,s(s({ref:t},c),{},{components:n})):r.createElement(f,s({ref:t},c))}));function g(e,t){var n=arguments,o=t&&t.mdxType;if("string"==typeof e||o){var i=n.length,s=new Array(i);s[0]=d;var a={};for(var l in t)hasOwnProperty.call(t,l)&&(a[l]=t[l]);a.originalType=e,a.mdxType="string"==typeof e?e:o,s[1]=a;for(var u=2;u{n.r(t),n.d(t,{assets:()=>l,contentTitle:()=>s,default:()=>p,frontMatter:()=>i,metadata:()=>a,toc:()=>u});var r=n(7462),o=(n(7294),n(3905));const i={slug:"edge",title:"Otomi at the edge",sidebar_label:"Edge"},s=void 0,a={unversionedId:"use-cases/edge",id:"use-cases/edge",title:"Otomi at the edge",description:"Introduction",source:"@site/product/use-cases/edge.md",sourceDirName:"use-cases",slug:"/use-cases/edge",permalink:"/product/use-cases/edge",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/edge.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"edge",title:"Otomi at the edge",sidebar_label:"Edge"}},l={},u=[{value:"Introduction",id:"introduction",level:2},{value:"How Otomi supports edge computing using Kubernetes",id:"how-otomi-supports-edge-computing-using-kubernetes",level:2}],c={toc:u};function p(e){let{components:t,...i}=e;return(0,o.kt)("wrapper",(0,r.Z)({},c,i,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h2",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,"Edge computing is an approach where you run applications as close as possible to its data sources or end users. One of the benefits is improved response times. "),(0,o.kt)("p",null,"However, managing edge applications using Kubernetes comes with challenges, like:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Deploy and update applications consistently accross multiple clusters"),(0,o.kt)("li",{parentName:"ul"},"Manage the run-time specifications for the applications like ingress, certificates, DNS, network policies, etc."),(0,o.kt)("li",{parentName:"ul"},"Lifecycle management of all supporting tools"),(0,o.kt)("li",{parentName:"ul"},"Using managed Kubernetes services in different clouds/infrastructures")),(0,o.kt)("h2",{id:"how-otomi-supports-edge-computing-using-kubernetes"},"How Otomi supports edge computing using Kubernetes"),(0,o.kt)("p",null,"One of the benefits of Otomi is that everything managed by Otomi can be specified in a single values file. This enables you to not only define the applications workloads that need to be running on the cluster, but also all the required tools and configuration to support and secure the workloads."),(0,o.kt)("p",null,"Let's explain this with an example:"),(0,o.kt)("p",null,"Suppose you have 2 application workloads that you would like to run on multiple Kubernetes clusters in multiple geographic regions, using different public cloud providers (AWS, Azure, GCP) and different Kubernetes versions (1.22 and 1.23). Next to the 2 workloads, you also would like to use Istio for mTLS, cert-manager for certificates, ingress/egress network policies for isolation and HTTP response headers. Because you can not afford using L7 load balancers with WAF features in the different clouds, you would like to implement Nginx ingress with Modsecurity and OWASP filtering. The following picture shows the desired situation:"),(0,o.kt)("p",null,(0,o.kt)("img",{alt:"edge",src:n(2300).Z,width:"1496",height:"1398"})),(0,o.kt)("p",null,"Read ",(0,o.kt)("a",{parentName:"p",href:"/docs/for-ops/how-to/core-only"},"this")," how-to to learn more about installing Otomi at the edge."))}p.isMDXComponent=!0},2300:(e,t,n)=>{n.d(t,{Z:()=>r});const r=n.p+"assets/images/edge-173d01e1fe3f7ac45484237e916968e3.png"}}]); \ No newline at end of file diff --git a/assets/js/73148982.041cb4ba.js b/assets/js/73148982.8d276d5c.js similarity index 99% rename from assets/js/73148982.041cb4ba.js rename to assets/js/73148982.8d276d5c.js index c7280882c..3766cd94b 100644 --- a/assets/js/73148982.041cb4ba.js +++ b/assets/js/73148982.8d276d5c.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[1409],{3905:(e,t,i)=>{i.d(t,{Zo:()=>c,kt:()=>m});var o=i(7294);function r(e,t,i){return t in e?Object.defineProperty(e,t,{value:i,enumerable:!0,configurable:!0,writable:!0}):e[t]=i,e}function n(e,t){var i=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);t&&(o=o.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),i.push.apply(i,o)}return i}function a(e){for(var t=1;t=0||(r[i]=e[i]);return r}(e,t);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,i)&&(r[i]=e[i])}return r}var l=o.createContext({}),d=function(e){var t=o.useContext(l),i=t;return e&&(i="function"==typeof e?e(t):a(a({},t),e)),i},c=function(e){var t=d(e.components);return o.createElement(l.Provider,{value:t},e.children)},u={inlineCode:"code",wrapper:function(e){var t=e.children;return o.createElement(o.Fragment,{},t)}},h=o.forwardRef((function(e,t){var i=e.components,r=e.mdxType,n=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),h=d(i),m=r,p=h["".concat(l,".").concat(m)]||h[m]||u[m]||n;return i?o.createElement(p,a(a({ref:t},c),{},{components:i})):o.createElement(p,a({ref:t},c))}));function m(e,t){var i=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var n=i.length,a=new Array(n);a[0]=h;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:r,a[1]=s;for(var d=2;d{i.r(t),i.d(t,{assets:()=>l,contentTitle:()=>a,default:()=>u,frontMatter:()=>n,metadata:()=>s,toc:()=>d});var o=i(7462),r=(i(7294),i(3905));const n={slug:"v1",title:"END USER LICENSE AGREEMENT",sidebar_label:"EULA"},a=void 0,s={unversionedId:"eula/v1",id:"eula/v1",title:"END USER LICENSE AGREEMENT",description:"This EULA is applicable to the usage of Otomi Console and Otomi API.",source:"@site/product/eula/v1.md",sourceDirName:"eula",slug:"/eula/v1",permalink:"/product/eula/v1",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/eula/v1.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"v1",title:"END USER LICENSE AGREEMENT",sidebar_label:"EULA"},sidebar:"mainSidebar",previous:{title:"Serverless",permalink:"/product/use-cases/serverless"}},l={},d=[{value:"1. The Mechanics of the Agreement",id:"1-the-mechanics-of-the-agreement",level:2},{value:"2. License",id:"2-license",level:2},{value:"3. Term",id:"3-term",level:2},{value:"4. Fees and Payment",id:"4-fees-and-payment",level:2},{value:"5. Termination",id:"5-termination",level:2},{value:"6. Representations and Warranties",id:"6-representations-and-warranties",level:2},{value:"7. Confidentiality",id:"7-confidentiality",level:2},{value:"8. End User Information, Feedback, Reservation of Rights, & Review",id:"8-end-user-information-feedback-reservation-of-rights--review",level:2},{value:"9. Review",id:"9-review",level:2},{value:"10. Limitations",id:"10--limitations",level:2},{value:"11. Governing Law and Claims.",id:"11--governing-law-and-claims",level:2},{value:"12. Miscellaneous",id:"12--miscellaneous",level:2},{value:"13. Definitions",id:"13--definitions",level:2}],c={toc:d};function u(e){let{components:t,...i}=e;return(0,r.kt)("wrapper",(0,o.Z)({},c,i,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"This EULA is applicable to the usage of Otomi Console and Otomi API."),(0,r.kt)("h1",{id:"otomi-console--api-end-user-license-agreement"},"OTOMI CONSOLE & API END USER LICENSE AGREEMENT"),(0,r.kt)("hr",null),(0,r.kt)("p",null,"PLEASE READ THIS AGREEMENT CAREFULLY BEFORE USING SOFTWARE FROM RED KUBES B.V.. (\u201cRED KUBES\u201d). BY USING RED KUBES SOFTWARE, USER SIGNIFIES ITS ASSENT TO AND ACCEPTANCE OF THIS AGREEMENT AND ACKNOWLEDGES IT HAS READ AND UNDERSTANDS THIS AGREEMENT. IF USER DOES NOT ACCEPT THE TERMS OF THIS AGREEMENT, THEN IT MUST NOT USE RED KUBES SOFTWARE.\nThis Red Kubes End User Agreement is between the User and Red Kubes and addresses relevant considerations that apply to Red Kubes Products, open source software, and our subscription business model. "),(0,r.kt)("h2",{id:"1-the-mechanics-of-the-agreement"},"1. The Mechanics of the Agreement"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Ordering. The Agreement applies to Red Kubes Products for which you acquire the right to access or use, including Subscriptions, access to Red Kubes Online Properties and other Red Kubes offerings. "),(0,r.kt)("li",{parentName:"ol"},"Structure. The Agreement consists of two components: (1) the General Terms and (2) the Product Appendices applicable to Your Products. Certain terms are defined in the General Terms or in the Definitions section at the end of the General Terms. ")),(0,r.kt)("h2",{id:"2-license"},"2. License"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Software License. Subject to your ongoing compliance with all the terms and conditions of this Agreement, Red Kubes hereby grants you a non-exclusive, non-sublicensable, non-transferrable, worldwide, revocable license to download and use the Software, specifically the Community Edition, for your own internal business operation only. "),(0,r.kt)("li",{parentName:"ol"},"License Restrictions. You will not: (a) copy or use the Software in any manner except as expressly permitted in this Agreement; (b) reverse engineer, disassemble, or decompile the Software (except to the extent such restrictions are prohibited by law); (c) alter, modify, enhance or prepare any derivative work from or of the Software; (d) alter or remove any proprietary notices in the Software; or (e) export the Software in violation any export laws or regulations. If you do not comply with the license terms or the foregoing restrictions, Red Kubes may terminate or suspend your license to the Software until you come into compliance with such terms and restrictions.\nThe Software may contain disabling codes that prevent use of the Software outside of the authorized scope and may contain functionality such that the Software reports to Red Kubes certain general metric information about your use of the Software. "),(0,r.kt)("li",{parentName:"ol"},"Third Party Components and Third Party Software. The Software may include third party software components provided under separate license terms (\u201cThird Party Components\u201d), including open source software from the Otomi Project. Nothing in this Agreement limits your rights to obtain and use the Third Party Components under the separate license terms that are applicable to each Third Party Component. However the Software is made available to you only pursuant to this Agreement. In addition, Red Kubes may in its sole discretion, make available other third party software (\u201cThird Party Software\u201d) embedded in, or otherwise provided with, the Software. Third Party Software is expressly excluded from the defined term \u201cSoftware\u201d as used throughout this Agreement. Your use of the Third Party Software is subject to the applicable third party license terms as set forth here, and such Third Party Software is not licensed to you under the terms of this Agreement. If you do not agree to abide by the applicable license terms for the Third Party Software, then you may not access or use the Software or the Third Party Software. You are solely and exclusively responsible for determining if you are permitted to use the Third Party Software and you should address any questions in this regard directly to the relevant Third Party Software licensor. ")),(0,r.kt)("h2",{id:"3-term"},"3. Term"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Agreement Term. The Agreement begins on the Effective Date and continues until it is terminated as set forth below. ")),(0,r.kt)("h2",{id:"4-fees-and-payment"},"4. Fees and Payment"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"The Software is made available to you under this Agreement free of charge. ")),(0,r.kt)("h2",{id:"5-termination"},"5. Termination"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Termination. This Agreement will remain in effect until terminated. You may terminate this Agreement at any time, for any reason or no reason, by ceasing all use of the Software and deleting all copies in your possession or control. Red Kubes may terminate this Agreement at any time, for any reason or no reason, upon notice by any method, including without limitation a post to the web page from which you downloaded the Software or an email sent to an email address you provided when you downloaded the Software. "),(0,r.kt)("li",{parentName:"ol"},"Effect of Termination; Survival. The termination of this Agreement will not terminate or suspend other provisions of the Agreement.")),(0,r.kt)("h2",{id:"6-representations-and-warranties"},"6. Representations and Warranties"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Red Kubes represents and warrants that (a) it has the authority to enter into this Agreement, and (b) to its knowledge, the Software does not, at the time of delivery to you, include malicious mechanisms or code for the purpose of damaging or corrupting the Software.. User represents and warrants that (a) it has the authority to enter into this Agreement, and (b) its use of Red Kubes Products will comply with all applicable laws, and it will not use the Red Kubes Products for any illegal activity. "),(0,r.kt)("li",{parentName:"ol"},"To the maximum extent permitted by applicable law and except as expressly provided in section 6.1, the Red Kubes Products are provided \u2018 as is\u2019 and without any representations or warranties express or implied, and Red Kubes disclaims all such representations and warranties, including the implied warranties of merchantability, non-infringement, and fitness for a particular purpose, and any warranties implied by the course of dealing of usage of trade. Red Kubes and its suppliers do not represent or warrant that the Red Kubes Products will be uninterrupted, secure, error free, accurate or complete or comply with regulatory requirements, or that Red Kubes will correct all errors. In the event of a breach of the warranties set forts in section 6.1., your exclusive remedy, and Red Kubes\u2019 entire liability, will be the re-performance of re-delivery of the deficient Red Kubes Product, or if Red Kubes cannot substantially correct a breach in a commercially reasonable manner, termination of the relevant Red Kubes Product. . "),(0,r.kt)("li",{parentName:"ol"},"The Red Kubes Products have not been tested in all situations under which they may be used. Red Kubes will not be liable for the results obtained through use of the Red Kubes Products and you are solely responsible for determining appropriate uses for the Red Kubes Products and for all results of such use. In particular, Red Kubes Products are not specifically designed, manufactured or intended for use in (a) the design, planning, construction, maintenance, control, or direct operation of nuclear facilities, (b) aircraft control, navigation, or communication systems (c) weapons systems, (d) direct life support systems (e) or other similar hazardous environments. ")),(0,r.kt)("h2",{id:"7-confidentiality"},"7. Confidentiality"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Recipient (a) may not disclose Confidential Information of a Discloser to any third party unless Discloser approves the disclosure in writing or the disclosure is otherwise permitted under this Section 7; (b) will use the same degree of care to protect Confidential Information of Discloser as it uses to protect its own confidential information of a similar nature, but in no event less than reasonable care; and (c) may disclose Confidential Information of the Discloser only to its employees, Affiliates, agents and contractors with a need to know, and to its auditors and legal counsel, in each case, who are under a written obligation (or other professional obligation) to keep such information confidential using standards of confidentiality no less restrictive than those required by this Section 7. These obligations will continue for a period of two (2) years following initial disclosure of the particular Confidential Information. A Recipient may disclose Confidential Information if it is required to do so by applicable law, regulation or court order but, where legally permissible, will provide advance notice to the Discloser to enable the Discloser to seek a protective order or other similar protection if feasible. \u201cRecipient\u201d is the party receiving Confidential Information under this Agreement. \u201cDiscloser\u201d is a party disclosing Confidential Information under this Agreement"),(0,r.kt)("li",{parentName:"ol"},"Information is not Confidential Information, if: (a) the information is or becomes publicly available other than as a result of the Recipient\u2019s breach of this Agreement, (b) the Recipient, at the time of disclosure, knows or possesses the information without obligation of confidentiality or thereafter obtains the information from a third party not under an obligation of confidentiality; (c) the Recipient independently develops the information without use of the Discloser\u2019s Confidential Information, (d) the information is generally known or easily developed by someone with ordinary skills in the business of the Recipient, or (e) the information is licensed under an Open Source License (as defined by the Open Source Initiative (",(0,r.kt)("a",{parentName:"li",href:"https://opensource.org/"},"https://opensource.org/"),")).\n7.3 Confidential Information that is disclosed prior to termination of this Agreement will remain subject to this Agreement for the period set forth above. Upon written request of the Discloser, the Recipient will promptly return or destroy all Confidential Information, except for Confidential Information stored in routine back-up media not accessible during the ordinary course of business. ")),(0,r.kt)("h2",{id:"8-end-user-information-feedback-reservation-of-rights--review"},"8. End User Information, Feedback, Reservation of Rights, & Review"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"End User Information. If you provide End User Information in connection with your use of or access to Red Kubes Products, you agree that, subject to Section 7, Red Kubes, its Affiliates, and Suppliers may use such End User Information in connection with providing the Red Kubes Products. You agree that your provision (and Red Kubes\u2019 use) of End User Information under this Agreement does not require any additional consents or licenses, will be in compliance with applicable law, and will not violate any intellectual property, proprietary, privacy, or other right of any third party. As between Red Kubes and you, you retain all other rights in and to End User Information. "),(0,r.kt)("li",{parentName:"ol"},"Feedback. You may be asked to voluntarily provide Red Kubes with Feedback in connection with Red Kubes Products, but have no obligation to do so. If you choose to do so, Red Kubes may use Feedback for any purpose, including incorporating the Feedback into, or using the Feedback to develop and improve Red Kubes Products and other Red Kubes offerings without attribution or compensation. You grant Red Kubes a perpetual and irrevocable license to use all Feedback for any purpose. You agree to provide Feedback to Red Kubes only in compliance with applicable laws and you represent that you have the authority to provide the Feedback and that Feedback will not include proprietary information of a third party. "),(0,r.kt)("li",{parentName:"ol"},"Reservation of Rights. Red Kubes grants to you only those rights expressly granted in\nthe Agreement with respect to the Red Kubes Products and reserves all other rights in and to the Red Kubes Products (including all intellectual property rights). Red Kubes may collect and use for any purpose aggregate anonymous benchmark data about your use of the Red Kubes Products. Nothing in this Agreement will limit Red Kubes from providing software, materials, or services for itself or other clients, irrespective of the possible similarity of such software, materials or services to those that might be delivered to you. The terms of Section 7 will not prohibit or restrict either party's right to develop, use or market products or services similar to or competitive with the other party; provided, however, that neither party is relieved of its obligations under this Agreement. ")),(0,r.kt)("h2",{id:"9-review"},"9. Review"),(0,r.kt)("p",null,"While this Agreement is in effect and for one year thereafter, Red Kubes or its designee, acting in accordance with Section 7, may inspect your facilities and records to verify your compliance with this Agreement. You agree to (a) respond promptly to requests for information, documents and/or records, (b) grant appropriate access for on-site visits in order to verify your compliance, and (c) reasonably cooperate in connection with any such verification. Red Kubes will provide at least ten (10) days prior written notice for any on-site visits, and will conduct onsite visits during regular business hours in a manner that reasonably minimizes interference with your business. If Red Kubes notifies you of any noncompliance, then you will resolve the non-compliance within fifteen (15) days from the date of notice. "),(0,r.kt)("h2",{id:"10--limitations"},"10. Limitations"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Disclaimer of damages. To the maximum extent permitted by applicable law, neither party, not its Affiliates, will be liable for any incidental, consequential, special, indirect, exemplary or punitive damages, of for any damages for lost or damaged data, lost profits, lost savings of business or service interruption, even if such party was advised of the possibility of such damages, and regardless of the failure of essential purpose of any limited remedy. "),(0,r.kt)("li",{parentName:"ol"},"Limitations of liability. To the maximum extent permitted by applicable law, Red Kubes\u2019 and its Affiliates\u2019 total and aggregate liability with respect to any claim relating to or arising out of this Agreement will not exceed ten euros with respect to the particular Red Kubes Product given rise to liability under the most applicable ordering document during the twelve (12) months immediately preceding the first event giving rise to such claim. This limitation applies regardless of the nature of the claim, whether contract, tort (including negligence), statute or other legal theory. "),(0,r.kt)("li",{parentName:"ol"},"No exclusion or limitation of liability. Notwithstanding any other provision of this Agreement and / or any offer, Red Kubes does not exclude or limit liability for (a) personal injury or death to the extent that such injury or death results from the negligence or willful default of Red Kubes, its agents, Affiliates, or subcontractors; (b) any fraudulent misrepresentation upon which the claiming party can be shown to have relied; or (c) any other liability which is not permissible at law to exclude or limit. ")),(0,r.kt)("h2",{id:"11--governing-law-and-claims"},"11. Governing Law and Claims."),(0,r.kt)("p",null,"The Agreement, and any claim, controversy or dispute related to the Agreement, are governed by and construed in accordance with the Dutch law without giving effect to any conflicts of laws provisions. To the extent permissible, the United Nations Convention on Contracts for the International Sale of Goods will not apply, even if adopted as part of the Dutch law. Any claim, suit, action or proceeding arising out of or relating to this Agreement or its subject matter will be brought exclusively in the courts of the Netherlands and each party irrevocably submits to the exclusive jurisdiction and venue. No claim or action, regardless of form, arising out of this Agreement may be brought by either party more than one (1) year after the party first became aware, or reasonably should have been aware, of the basis for the claim. "),(0,r.kt)("h2",{id:"12--miscellaneous"},"12. Miscellaneous"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Notices. Notices must be in English, in writing, and will be deemed given upon receipt, after being sent using a method that provides for positive confirmation of delivery to the address(es) or email address provided by you, including through an automated receipt or by electronic log. Any notice from you to Red Kubes must include a copy sent to: Red Kubes\u2019 email address ",(0,r.kt)("a",{parentName:"li",href:"mailto:info@redkubes.com."},"info@redkubes.com.")," "),(0,r.kt)("li",{parentName:"ol"},"Assignment. Either party may upon written notice: (a) assign this Agreement to an Affiliate if the Affiliate is able to satisfy the assigning party\u2019s obligations under the Agreement and the assignment will not affect the non-assigning party\u2019s obligations under the Agreement; and (b) assign this Agreement to a successor or acquirer pursuant to a merger or sale of all or substantially all of such party\u2019s assets. Any other assignment will be deemed void and ineffective without the prior written consent of the other party. Subject to the foregoing, this Agreement will be binding upon and will insure to the benefit of the parties and their respective successors and permitted assigns."),(0,r.kt)("li",{parentName:"ol"},"Waiver. A waiver by a party under this Agreement is only valid if in writing and signed by an authorized representative of such party. A delay or failure of a party to exercise any rights under this Agreement will not constitute or be deemed a waiver or forfeiture of such rights. "),(0,r.kt)("li",{parentName:"ol"},"Independent Contractors. The parties are independent contractors and nothing in this Agreement creates an employment, partnership or agency relationship between the parties or any Affiliate. Each party is solely responsible for supervision, control and payment of its personnel. "),(0,r.kt)("li",{parentName:"ol"},"Third Party Beneficiaries. This Agreement is binding on the parties to this Agreement and, other than as expressly provided in the Agreement, nothing in this Agreement grants any other person or entity any right, benefit or remedy. "),(0,r.kt)("li",{parentName:"ol"},"Force Majeure. Neither party is responsible for nonperformance or delay in performance of its obligations due to causes beyond its reasonable control. "),(0,r.kt)("li",{parentName:"ol"},"Complete Agreement and Order of Precedence. The Agreement represents the complete agreement between the parties with respect to its subject matter and supersedes all prior and contemporaneous agreements and proposals, whether written or oral, with respect to such subject matter. Any terms contained in any other documentation that you deliver to Red Kubes, are void and will not become part of the Agreement or otherwise bind the parties. If there is a conflict between the General Terms and the Product Appendices, the General Terms will control unless otherwise expressly provided in the Product Appendices. "),(0,r.kt)("li",{parentName:"ol"},"Counterparts. This Agreement may be executed in counterparts, each of which will be deemed an original and all of which will constitute one and the same document. The parties may exchange signature pages by email or electronic signature process and such signatures will be effective to bind the parties to the Agreement. "),(0,r.kt)("li",{parentName:"ol"},"Severable. If any provision of this Agreement is held by a court of competent jurisdiction to be invalid or unenforceable, the remaining provisions of this Agreement will remain in effect to the greatest extent permitted by law.")),(0,r.kt)("h2",{id:"13--definitions"},"13. Definitions"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"\u201cAffiliate\u201d means an entity that owns or controls, is owned or controlled by, or is under common control or ownership with a party, where \u201ccontrol\u201d is the possession, direct or indirect, of the power to direct or cause the direction of the management and policies of an entity, whether through ownership of voting securities, by contract or otherwise. "),(0,r.kt)("li",{parentName:"ol"},"\u201cBusiness Partner\u201d means a cloud provider, distributor, reseller, OEM or other third party authorized to resell or distribute Red Kubes Products. "),(0,r.kt)("li",{parentName:"ol"},"\u201cBusiness Partner order\u201d means an order for a Red Kubes Product placed through a Business Partner. "),(0,r.kt)("li",{parentName:"ol"},"\u201cEnd User\u201d or \u201cyou\u201d means the person or entity acquiring the right to use or access the Red Kubes Products and which is a party to this Agreement. "),(0,r.kt)("li",{parentName:"ol"},"\u201cEnd User Information\u201d means any data, information, software or other materials that you provide to Red Kubes under the Agreement. "),(0,r.kt)("li",{parentName:"ol"},"\u201cConfidential Information\u201d means information disclosed by the Discloser to the Recipient during the term of the Agreement that (i) is marked confidential; (ii) if disclosed orally, is clearly described as confidential at the time of disclosure and is subsequently set forth in writing, marked confidential, and sent to the Recipient within thirty (30) days following the oral disclosure; or (iii) is of a nature that the Recipient knows is confidential to the Discloser or should reasonably be expected to know is confidential. "),(0,r.kt)("li",{parentName:"ol"},"\u201cEffective Date\u201d means earliest of (a) the date of the last signature on this Agreement, (b) your online acceptance of the Agreement, and (c) when you first receive access to a Red Kubes Product. "),(0,r.kt)("li",{parentName:"ol"},"\u201cFeedback\u201d means any ideas, suggestions, proposals or other feedback you may provide regarding Red Kubes Products. "),(0,r.kt)("li",{parentName:"ol"},"\u201cGeneral Terms\u201d means the terms contained in Sections 1 \u2013 13 of this document. "),(0,r.kt)("li",{parentName:"ol"},"\u201cProduct Appendices\u201d means (a) the Red Kubes Product Appendices that are incorporated into an applicable statement of work. "),(0,r.kt)("li",{parentName:"ol"},"\u201cRed Kubes Products\u201d means Software, Services, Subscriptions and other Red Kubes branded offerings made available by Red Kubes. "),(0,r.kt)("li",{parentName:"ol"},"\u201cSoftware\u201d means Red Kubes branded software that is included in Red Kubes Product offerings. "),(0,r.kt)("li",{parentName:"ol"},"\u201cSubscription\u201d means a time bound Red Kubes Services offering, other than Professional Services. "),(0,r.kt)("li",{parentName:"ol"},"\u201cSupplier\u201d means a third party that provides service(s) to Red Kubes in order for Red Kubes to offer Services to its customers and/or Business Partners."),(0,r.kt)("li",{parentName:"ol"},"\u201cYour Products\u201d means the Red Kubes Products that you have purchased, licensed, or otherwise acquired the right to access or use.")))}u.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[1409],{3905:(e,t,i)=>{i.d(t,{Zo:()=>c,kt:()=>m});var o=i(7294);function r(e,t,i){return t in e?Object.defineProperty(e,t,{value:i,enumerable:!0,configurable:!0,writable:!0}):e[t]=i,e}function n(e,t){var i=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);t&&(o=o.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),i.push.apply(i,o)}return i}function a(e){for(var t=1;t=0||(r[i]=e[i]);return r}(e,t);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,i)&&(r[i]=e[i])}return r}var l=o.createContext({}),d=function(e){var t=o.useContext(l),i=t;return e&&(i="function"==typeof e?e(t):a(a({},t),e)),i},c=function(e){var t=d(e.components);return o.createElement(l.Provider,{value:t},e.children)},u={inlineCode:"code",wrapper:function(e){var t=e.children;return o.createElement(o.Fragment,{},t)}},h=o.forwardRef((function(e,t){var i=e.components,r=e.mdxType,n=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),h=d(i),m=r,p=h["".concat(l,".").concat(m)]||h[m]||u[m]||n;return i?o.createElement(p,a(a({ref:t},c),{},{components:i})):o.createElement(p,a({ref:t},c))}));function m(e,t){var i=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var n=i.length,a=new Array(n);a[0]=h;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:r,a[1]=s;for(var d=2;d{i.r(t),i.d(t,{assets:()=>l,contentTitle:()=>a,default:()=>u,frontMatter:()=>n,metadata:()=>s,toc:()=>d});var o=i(7462),r=(i(7294),i(3905));const n={slug:"v1",title:"END USER LICENSE AGREEMENT",sidebar_label:"EULA"},a=void 0,s={unversionedId:"eula/v1",id:"eula/v1",title:"END USER LICENSE AGREEMENT",description:"This EULA is applicable to the usage of Otomi Console and Otomi API.",source:"@site/product/eula/v1.md",sourceDirName:"eula",slug:"/eula/v1",permalink:"/product/eula/v1",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/eula/v1.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"v1",title:"END USER LICENSE AGREEMENT",sidebar_label:"EULA"},sidebar:"mainSidebar",previous:{title:"Serverless",permalink:"/product/use-cases/serverless"}},l={},d=[{value:"1. The Mechanics of the Agreement",id:"1-the-mechanics-of-the-agreement",level:2},{value:"2. License",id:"2-license",level:2},{value:"3. Term",id:"3-term",level:2},{value:"4. Fees and Payment",id:"4-fees-and-payment",level:2},{value:"5. Termination",id:"5-termination",level:2},{value:"6. Representations and Warranties",id:"6-representations-and-warranties",level:2},{value:"7. Confidentiality",id:"7-confidentiality",level:2},{value:"8. End User Information, Feedback, Reservation of Rights, & Review",id:"8-end-user-information-feedback-reservation-of-rights--review",level:2},{value:"9. Review",id:"9-review",level:2},{value:"10. Limitations",id:"10--limitations",level:2},{value:"11. Governing Law and Claims.",id:"11--governing-law-and-claims",level:2},{value:"12. Miscellaneous",id:"12--miscellaneous",level:2},{value:"13. Definitions",id:"13--definitions",level:2}],c={toc:d};function u(e){let{components:t,...i}=e;return(0,r.kt)("wrapper",(0,o.Z)({},c,i,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"This EULA is applicable to the usage of Otomi Console and Otomi API."),(0,r.kt)("h1",{id:"otomi-console--api-end-user-license-agreement"},"OTOMI CONSOLE & API END USER LICENSE AGREEMENT"),(0,r.kt)("hr",null),(0,r.kt)("p",null,"PLEASE READ THIS AGREEMENT CAREFULLY BEFORE USING SOFTWARE FROM RED KUBES B.V.. (\u201cRED KUBES\u201d). BY USING RED KUBES SOFTWARE, USER SIGNIFIES ITS ASSENT TO AND ACCEPTANCE OF THIS AGREEMENT AND ACKNOWLEDGES IT HAS READ AND UNDERSTANDS THIS AGREEMENT. IF USER DOES NOT ACCEPT THE TERMS OF THIS AGREEMENT, THEN IT MUST NOT USE RED KUBES SOFTWARE.\nThis Red Kubes End User Agreement is between the User and Red Kubes and addresses relevant considerations that apply to Red Kubes Products, open source software, and our subscription business model. "),(0,r.kt)("h2",{id:"1-the-mechanics-of-the-agreement"},"1. The Mechanics of the Agreement"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Ordering. The Agreement applies to Red Kubes Products for which you acquire the right to access or use, including Subscriptions, access to Red Kubes Online Properties and other Red Kubes offerings. "),(0,r.kt)("li",{parentName:"ol"},"Structure. The Agreement consists of two components: (1) the General Terms and (2) the Product Appendices applicable to Your Products. Certain terms are defined in the General Terms or in the Definitions section at the end of the General Terms. ")),(0,r.kt)("h2",{id:"2-license"},"2. License"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Software License. Subject to your ongoing compliance with all the terms and conditions of this Agreement, Red Kubes hereby grants you a non-exclusive, non-sublicensable, non-transferrable, worldwide, revocable license to download and use the Software, specifically the Community Edition, for your own internal business operation only. "),(0,r.kt)("li",{parentName:"ol"},"License Restrictions. You will not: (a) copy or use the Software in any manner except as expressly permitted in this Agreement; (b) reverse engineer, disassemble, or decompile the Software (except to the extent such restrictions are prohibited by law); (c) alter, modify, enhance or prepare any derivative work from or of the Software; (d) alter or remove any proprietary notices in the Software; or (e) export the Software in violation any export laws or regulations. If you do not comply with the license terms or the foregoing restrictions, Red Kubes may terminate or suspend your license to the Software until you come into compliance with such terms and restrictions.\nThe Software may contain disabling codes that prevent use of the Software outside of the authorized scope and may contain functionality such that the Software reports to Red Kubes certain general metric information about your use of the Software. "),(0,r.kt)("li",{parentName:"ol"},"Third Party Components and Third Party Software. The Software may include third party software components provided under separate license terms (\u201cThird Party Components\u201d), including open source software from the Otomi Project. Nothing in this Agreement limits your rights to obtain and use the Third Party Components under the separate license terms that are applicable to each Third Party Component. However the Software is made available to you only pursuant to this Agreement. In addition, Red Kubes may in its sole discretion, make available other third party software (\u201cThird Party Software\u201d) embedded in, or otherwise provided with, the Software. Third Party Software is expressly excluded from the defined term \u201cSoftware\u201d as used throughout this Agreement. Your use of the Third Party Software is subject to the applicable third party license terms as set forth here, and such Third Party Software is not licensed to you under the terms of this Agreement. If you do not agree to abide by the applicable license terms for the Third Party Software, then you may not access or use the Software or the Third Party Software. You are solely and exclusively responsible for determining if you are permitted to use the Third Party Software and you should address any questions in this regard directly to the relevant Third Party Software licensor. ")),(0,r.kt)("h2",{id:"3-term"},"3. Term"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Agreement Term. The Agreement begins on the Effective Date and continues until it is terminated as set forth below. ")),(0,r.kt)("h2",{id:"4-fees-and-payment"},"4. Fees and Payment"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"The Software is made available to you under this Agreement free of charge. ")),(0,r.kt)("h2",{id:"5-termination"},"5. Termination"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Termination. This Agreement will remain in effect until terminated. You may terminate this Agreement at any time, for any reason or no reason, by ceasing all use of the Software and deleting all copies in your possession or control. Red Kubes may terminate this Agreement at any time, for any reason or no reason, upon notice by any method, including without limitation a post to the web page from which you downloaded the Software or an email sent to an email address you provided when you downloaded the Software. "),(0,r.kt)("li",{parentName:"ol"},"Effect of Termination; Survival. The termination of this Agreement will not terminate or suspend other provisions of the Agreement.")),(0,r.kt)("h2",{id:"6-representations-and-warranties"},"6. Representations and Warranties"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Red Kubes represents and warrants that (a) it has the authority to enter into this Agreement, and (b) to its knowledge, the Software does not, at the time of delivery to you, include malicious mechanisms or code for the purpose of damaging or corrupting the Software.. User represents and warrants that (a) it has the authority to enter into this Agreement, and (b) its use of Red Kubes Products will comply with all applicable laws, and it will not use the Red Kubes Products for any illegal activity. "),(0,r.kt)("li",{parentName:"ol"},"To the maximum extent permitted by applicable law and except as expressly provided in section 6.1, the Red Kubes Products are provided \u2018 as is\u2019 and without any representations or warranties express or implied, and Red Kubes disclaims all such representations and warranties, including the implied warranties of merchantability, non-infringement, and fitness for a particular purpose, and any warranties implied by the course of dealing of usage of trade. Red Kubes and its suppliers do not represent or warrant that the Red Kubes Products will be uninterrupted, secure, error free, accurate or complete or comply with regulatory requirements, or that Red Kubes will correct all errors. In the event of a breach of the warranties set forts in section 6.1., your exclusive remedy, and Red Kubes\u2019 entire liability, will be the re-performance of re-delivery of the deficient Red Kubes Product, or if Red Kubes cannot substantially correct a breach in a commercially reasonable manner, termination of the relevant Red Kubes Product. . "),(0,r.kt)("li",{parentName:"ol"},"The Red Kubes Products have not been tested in all situations under which they may be used. Red Kubes will not be liable for the results obtained through use of the Red Kubes Products and you are solely responsible for determining appropriate uses for the Red Kubes Products and for all results of such use. In particular, Red Kubes Products are not specifically designed, manufactured or intended for use in (a) the design, planning, construction, maintenance, control, or direct operation of nuclear facilities, (b) aircraft control, navigation, or communication systems (c) weapons systems, (d) direct life support systems (e) or other similar hazardous environments. ")),(0,r.kt)("h2",{id:"7-confidentiality"},"7. Confidentiality"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Recipient (a) may not disclose Confidential Information of a Discloser to any third party unless Discloser approves the disclosure in writing or the disclosure is otherwise permitted under this Section 7; (b) will use the same degree of care to protect Confidential Information of Discloser as it uses to protect its own confidential information of a similar nature, but in no event less than reasonable care; and (c) may disclose Confidential Information of the Discloser only to its employees, Affiliates, agents and contractors with a need to know, and to its auditors and legal counsel, in each case, who are under a written obligation (or other professional obligation) to keep such information confidential using standards of confidentiality no less restrictive than those required by this Section 7. These obligations will continue for a period of two (2) years following initial disclosure of the particular Confidential Information. A Recipient may disclose Confidential Information if it is required to do so by applicable law, regulation or court order but, where legally permissible, will provide advance notice to the Discloser to enable the Discloser to seek a protective order or other similar protection if feasible. \u201cRecipient\u201d is the party receiving Confidential Information under this Agreement. \u201cDiscloser\u201d is a party disclosing Confidential Information under this Agreement"),(0,r.kt)("li",{parentName:"ol"},"Information is not Confidential Information, if: (a) the information is or becomes publicly available other than as a result of the Recipient\u2019s breach of this Agreement, (b) the Recipient, at the time of disclosure, knows or possesses the information without obligation of confidentiality or thereafter obtains the information from a third party not under an obligation of confidentiality; (c) the Recipient independently develops the information without use of the Discloser\u2019s Confidential Information, (d) the information is generally known or easily developed by someone with ordinary skills in the business of the Recipient, or (e) the information is licensed under an Open Source License (as defined by the Open Source Initiative (",(0,r.kt)("a",{parentName:"li",href:"https://opensource.org/"},"https://opensource.org/"),")).\n7.3 Confidential Information that is disclosed prior to termination of this Agreement will remain subject to this Agreement for the period set forth above. Upon written request of the Discloser, the Recipient will promptly return or destroy all Confidential Information, except for Confidential Information stored in routine back-up media not accessible during the ordinary course of business. ")),(0,r.kt)("h2",{id:"8-end-user-information-feedback-reservation-of-rights--review"},"8. End User Information, Feedback, Reservation of Rights, & Review"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"End User Information. If you provide End User Information in connection with your use of or access to Red Kubes Products, you agree that, subject to Section 7, Red Kubes, its Affiliates, and Suppliers may use such End User Information in connection with providing the Red Kubes Products. You agree that your provision (and Red Kubes\u2019 use) of End User Information under this Agreement does not require any additional consents or licenses, will be in compliance with applicable law, and will not violate any intellectual property, proprietary, privacy, or other right of any third party. As between Red Kubes and you, you retain all other rights in and to End User Information. "),(0,r.kt)("li",{parentName:"ol"},"Feedback. You may be asked to voluntarily provide Red Kubes with Feedback in connection with Red Kubes Products, but have no obligation to do so. If you choose to do so, Red Kubes may use Feedback for any purpose, including incorporating the Feedback into, or using the Feedback to develop and improve Red Kubes Products and other Red Kubes offerings without attribution or compensation. You grant Red Kubes a perpetual and irrevocable license to use all Feedback for any purpose. You agree to provide Feedback to Red Kubes only in compliance with applicable laws and you represent that you have the authority to provide the Feedback and that Feedback will not include proprietary information of a third party. "),(0,r.kt)("li",{parentName:"ol"},"Reservation of Rights. Red Kubes grants to you only those rights expressly granted in\nthe Agreement with respect to the Red Kubes Products and reserves all other rights in and to the Red Kubes Products (including all intellectual property rights). Red Kubes may collect and use for any purpose aggregate anonymous benchmark data about your use of the Red Kubes Products. Nothing in this Agreement will limit Red Kubes from providing software, materials, or services for itself or other clients, irrespective of the possible similarity of such software, materials or services to those that might be delivered to you. The terms of Section 7 will not prohibit or restrict either party's right to develop, use or market products or services similar to or competitive with the other party; provided, however, that neither party is relieved of its obligations under this Agreement. ")),(0,r.kt)("h2",{id:"9-review"},"9. Review"),(0,r.kt)("p",null,"While this Agreement is in effect and for one year thereafter, Red Kubes or its designee, acting in accordance with Section 7, may inspect your facilities and records to verify your compliance with this Agreement. You agree to (a) respond promptly to requests for information, documents and/or records, (b) grant appropriate access for on-site visits in order to verify your compliance, and (c) reasonably cooperate in connection with any such verification. Red Kubes will provide at least ten (10) days prior written notice for any on-site visits, and will conduct onsite visits during regular business hours in a manner that reasonably minimizes interference with your business. If Red Kubes notifies you of any noncompliance, then you will resolve the non-compliance within fifteen (15) days from the date of notice. "),(0,r.kt)("h2",{id:"10--limitations"},"10. Limitations"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Disclaimer of damages. To the maximum extent permitted by applicable law, neither party, not its Affiliates, will be liable for any incidental, consequential, special, indirect, exemplary or punitive damages, of for any damages for lost or damaged data, lost profits, lost savings of business or service interruption, even if such party was advised of the possibility of such damages, and regardless of the failure of essential purpose of any limited remedy. "),(0,r.kt)("li",{parentName:"ol"},"Limitations of liability. To the maximum extent permitted by applicable law, Red Kubes\u2019 and its Affiliates\u2019 total and aggregate liability with respect to any claim relating to or arising out of this Agreement will not exceed ten euros with respect to the particular Red Kubes Product given rise to liability under the most applicable ordering document during the twelve (12) months immediately preceding the first event giving rise to such claim. This limitation applies regardless of the nature of the claim, whether contract, tort (including negligence), statute or other legal theory. "),(0,r.kt)("li",{parentName:"ol"},"No exclusion or limitation of liability. Notwithstanding any other provision of this Agreement and / or any offer, Red Kubes does not exclude or limit liability for (a) personal injury or death to the extent that such injury or death results from the negligence or willful default of Red Kubes, its agents, Affiliates, or subcontractors; (b) any fraudulent misrepresentation upon which the claiming party can be shown to have relied; or (c) any other liability which is not permissible at law to exclude or limit. ")),(0,r.kt)("h2",{id:"11--governing-law-and-claims"},"11. Governing Law and Claims."),(0,r.kt)("p",null,"The Agreement, and any claim, controversy or dispute related to the Agreement, are governed by and construed in accordance with the Dutch law without giving effect to any conflicts of laws provisions. To the extent permissible, the United Nations Convention on Contracts for the International Sale of Goods will not apply, even if adopted as part of the Dutch law. Any claim, suit, action or proceeding arising out of or relating to this Agreement or its subject matter will be brought exclusively in the courts of the Netherlands and each party irrevocably submits to the exclusive jurisdiction and venue. No claim or action, regardless of form, arising out of this Agreement may be brought by either party more than one (1) year after the party first became aware, or reasonably should have been aware, of the basis for the claim. "),(0,r.kt)("h2",{id:"12--miscellaneous"},"12. Miscellaneous"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Notices. Notices must be in English, in writing, and will be deemed given upon receipt, after being sent using a method that provides for positive confirmation of delivery to the address(es) or email address provided by you, including through an automated receipt or by electronic log. Any notice from you to Red Kubes must include a copy sent to: Red Kubes\u2019 email address ",(0,r.kt)("a",{parentName:"li",href:"mailto:info@redkubes.com."},"info@redkubes.com.")," "),(0,r.kt)("li",{parentName:"ol"},"Assignment. Either party may upon written notice: (a) assign this Agreement to an Affiliate if the Affiliate is able to satisfy the assigning party\u2019s obligations under the Agreement and the assignment will not affect the non-assigning party\u2019s obligations under the Agreement; and (b) assign this Agreement to a successor or acquirer pursuant to a merger or sale of all or substantially all of such party\u2019s assets. Any other assignment will be deemed void and ineffective without the prior written consent of the other party. Subject to the foregoing, this Agreement will be binding upon and will insure to the benefit of the parties and their respective successors and permitted assigns."),(0,r.kt)("li",{parentName:"ol"},"Waiver. A waiver by a party under this Agreement is only valid if in writing and signed by an authorized representative of such party. A delay or failure of a party to exercise any rights under this Agreement will not constitute or be deemed a waiver or forfeiture of such rights. "),(0,r.kt)("li",{parentName:"ol"},"Independent Contractors. The parties are independent contractors and nothing in this Agreement creates an employment, partnership or agency relationship between the parties or any Affiliate. Each party is solely responsible for supervision, control and payment of its personnel. "),(0,r.kt)("li",{parentName:"ol"},"Third Party Beneficiaries. This Agreement is binding on the parties to this Agreement and, other than as expressly provided in the Agreement, nothing in this Agreement grants any other person or entity any right, benefit or remedy. "),(0,r.kt)("li",{parentName:"ol"},"Force Majeure. Neither party is responsible for nonperformance or delay in performance of its obligations due to causes beyond its reasonable control. "),(0,r.kt)("li",{parentName:"ol"},"Complete Agreement and Order of Precedence. The Agreement represents the complete agreement between the parties with respect to its subject matter and supersedes all prior and contemporaneous agreements and proposals, whether written or oral, with respect to such subject matter. Any terms contained in any other documentation that you deliver to Red Kubes, are void and will not become part of the Agreement or otherwise bind the parties. If there is a conflict between the General Terms and the Product Appendices, the General Terms will control unless otherwise expressly provided in the Product Appendices. "),(0,r.kt)("li",{parentName:"ol"},"Counterparts. This Agreement may be executed in counterparts, each of which will be deemed an original and all of which will constitute one and the same document. The parties may exchange signature pages by email or electronic signature process and such signatures will be effective to bind the parties to the Agreement. "),(0,r.kt)("li",{parentName:"ol"},"Severable. If any provision of this Agreement is held by a court of competent jurisdiction to be invalid or unenforceable, the remaining provisions of this Agreement will remain in effect to the greatest extent permitted by law.")),(0,r.kt)("h2",{id:"13--definitions"},"13. Definitions"),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"\u201cAffiliate\u201d means an entity that owns or controls, is owned or controlled by, or is under common control or ownership with a party, where \u201ccontrol\u201d is the possession, direct or indirect, of the power to direct or cause the direction of the management and policies of an entity, whether through ownership of voting securities, by contract or otherwise. "),(0,r.kt)("li",{parentName:"ol"},"\u201cBusiness Partner\u201d means a cloud provider, distributor, reseller, OEM or other third party authorized to resell or distribute Red Kubes Products. "),(0,r.kt)("li",{parentName:"ol"},"\u201cBusiness Partner order\u201d means an order for a Red Kubes Product placed through a Business Partner. "),(0,r.kt)("li",{parentName:"ol"},"\u201cEnd User\u201d or \u201cyou\u201d means the person or entity acquiring the right to use or access the Red Kubes Products and which is a party to this Agreement. "),(0,r.kt)("li",{parentName:"ol"},"\u201cEnd User Information\u201d means any data, information, software or other materials that you provide to Red Kubes under the Agreement. "),(0,r.kt)("li",{parentName:"ol"},"\u201cConfidential Information\u201d means information disclosed by the Discloser to the Recipient during the term of the Agreement that (i) is marked confidential; (ii) if disclosed orally, is clearly described as confidential at the time of disclosure and is subsequently set forth in writing, marked confidential, and sent to the Recipient within thirty (30) days following the oral disclosure; or (iii) is of a nature that the Recipient knows is confidential to the Discloser or should reasonably be expected to know is confidential. "),(0,r.kt)("li",{parentName:"ol"},"\u201cEffective Date\u201d means earliest of (a) the date of the last signature on this Agreement, (b) your online acceptance of the Agreement, and (c) when you first receive access to a Red Kubes Product. "),(0,r.kt)("li",{parentName:"ol"},"\u201cFeedback\u201d means any ideas, suggestions, proposals or other feedback you may provide regarding Red Kubes Products. "),(0,r.kt)("li",{parentName:"ol"},"\u201cGeneral Terms\u201d means the terms contained in Sections 1 \u2013 13 of this document. "),(0,r.kt)("li",{parentName:"ol"},"\u201cProduct Appendices\u201d means (a) the Red Kubes Product Appendices that are incorporated into an applicable statement of work. "),(0,r.kt)("li",{parentName:"ol"},"\u201cRed Kubes Products\u201d means Software, Services, Subscriptions and other Red Kubes branded offerings made available by Red Kubes. "),(0,r.kt)("li",{parentName:"ol"},"\u201cSoftware\u201d means Red Kubes branded software that is included in Red Kubes Product offerings. "),(0,r.kt)("li",{parentName:"ol"},"\u201cSubscription\u201d means a time bound Red Kubes Services offering, other than Professional Services. "),(0,r.kt)("li",{parentName:"ol"},"\u201cSupplier\u201d means a third party that provides service(s) to Red Kubes in order for Red Kubes to offer Services to its customers and/or Business Partners."),(0,r.kt)("li",{parentName:"ol"},"\u201cYour Products\u201d means the Red Kubes Products that you have purchased, licensed, or otherwise acquired the right to access or use.")))}u.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/8f69df39.129b4e23.js b/assets/js/8f69df39.935e1adc.js similarity index 81% rename from assets/js/8f69df39.129b4e23.js rename to assets/js/8f69df39.935e1adc.js index 1c85c4b03..c036b7d99 100644 --- a/assets/js/8f69df39.129b4e23.js +++ b/assets/js/8f69df39.935e1adc.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[8589],{3905:(e,t,a)=>{a.d(t,{Zo:()=>p,kt:()=>d});var n=a(7294);function r(e,t,a){return t in e?Object.defineProperty(e,t,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[t]=a,e}function l(e,t){var a=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),a.push.apply(a,n)}return a}function o(e){for(var t=1;t=0||(r[a]=e[a]);return r}(e,t);if(Object.getOwnPropertySymbols){var l=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(r[a]=e[a])}return r}var s=n.createContext({}),c=function(e){var t=n.useContext(s),a=t;return e&&(a="function"==typeof e?e(t):o(o({},t),e)),a},p=function(e){var t=c(e.components);return n.createElement(s.Provider,{value:t},e.children)},u={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},m=n.forwardRef((function(e,t){var a=e.components,r=e.mdxType,l=e.originalType,s=e.parentName,p=i(e,["components","mdxType","originalType","parentName"]),m=c(a),d=r,k=m["".concat(s,".").concat(d)]||m[d]||u[d]||l;return a?n.createElement(k,o(o({ref:t},p),{},{components:a})):n.createElement(k,o({ref:t},p))}));function d(e,t){var a=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var l=a.length,o=new Array(l);o[0]=m;var i={};for(var s in t)hasOwnProperty.call(t,s)&&(i[s]=t[s]);i.originalType=e,i.mdxType="string"==typeof e?e:r,o[1]=i;for(var c=2;c{a.r(t),a.d(t,{assets:()=>s,contentTitle:()=>o,default:()=>u,frontMatter:()=>l,metadata:()=>i,toc:()=>c});var n=a(7462),r=(a(7294),a(3905));const l={slug:"aws",title:"AWS",sidebar_label:"AWS"},o="Install Otomi on EKS with DNS using Route53",i={unversionedId:"get-started/installation/aws",id:"get-started/installation/aws",title:"AWS",description:"Prerequisites",source:"@site/docs/get-started/installation/aws.md",sourceDirName:"get-started/installation",slug:"/get-started/installation/aws",permalink:"/docs/get-started/installation/aws",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/tree/main/docs/get-started/installation/aws.md",tags:[],version:"current",frontMatter:{slug:"aws",title:"AWS",sidebar_label:"AWS"},sidebar:"mainSidebar",previous:{title:"Overview",permalink:"/docs/get-started/installation/overview"},next:{title:"Azure",permalink:"/docs/get-started/installation/azure"}},s={},c=[{value:"Prerequisites",id:"prerequisites",level:2},{value:"Additional resources",id:"additional-resources",level:2},{value:"Create an EKS cluster",id:"create-an-eks-cluster",level:2},{value:"Add a CNI",id:"add-a-cni",level:2},{value:"Configure Route53",id:"configure-route53",level:2},{value:"Create the values.yaml file",id:"create-the-valuesyaml-file",level:2},{value:"Install Otomi on EKS",id:"install-otomi-on-eks",level:2}],p={toc:c};function u(e){let{components:t,...a}=e;return(0,r.kt)("wrapper",(0,n.Z)({},p,a,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("h1",{id:"install-otomi-on-eks-with-dns-using-route53"},"Install Otomi on EKS with DNS using Route53"),(0,r.kt)("h2",{id:"prerequisites"},"Prerequisites"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://aws.amazon.com/cli/"},"AWS CLI")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://cloud.google.com/sdk/docs/install"},"Terraform")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://kubernetes.io/docs/tasks/tools/"},"Helm"))),(0,r.kt)("h2",{id:"additional-resources"},"Additional resources"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},"If you use VSCode, hover over variables to see the description/type in .tf and .tfvars files with the ",(0,r.kt)("a",{parentName:"li",href:"https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform"},"Terraform extension")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://learn.hashicorp.com/tutorials/terraform/aws-build"},"How to setup aws cli and terraform"))),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-jsx",metastring:'title="AWS CLI Cheat Sheet"',title:'"AWS',CLI:!0,Cheat:!0,'Sheet"':!0},"# Obtain account\naws sts get-caller-identity\n# Obtain username and userarn\naws iam get-user\n# Obtain rolearn\naws iam list-roles\n# Obtain groups\naws iam list-groups\n")),(0,r.kt)("h2",{id:"create-an-eks-cluster"},"Create an EKS cluster"),(0,r.kt)("p",null,"Clone the Otomi Terraform repository:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"git clone https://github.com/redkubes/quickstart.git\ncd eks\n")),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},"Copy ",(0,r.kt)("inlineCode",{parentName:"li"},"example.tfvars")," file to ",(0,r.kt)("inlineCode",{parentName:"li"},"terraform.tfvars")," file and fill in missing configuration parameters"),(0,r.kt)("li",{parentName:"ul"},"Open a terminal and run the following:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"terraform init\n# install the EKS cluster\nterraform apply\n")),(0,r.kt)("p",null,"Get the credentials of the cluster:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"# Update your kubeconfig\n# Default: aws eks update-kubeconfig --name otomi\naws eks update-kubeconfig --name \n")),(0,r.kt)("h2",{id:"add-a-cni"},"Add a CNI"),(0,r.kt)("p",null,"To use the network policies feature in Otomi, make sure to install the ",(0,r.kt)("a",{parentName:"p",href:"https://www.tigera.io/project-calico/"},"Calico")," CNI or any other CNI that supports Kubernetes network polices."),(0,r.kt)("p",null,"Install Tigera Operator:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"helm repo add projectcalico https://docs.tigera.io/calico/charts\nhelm repo update\nkubectl create namespace tigera-operator\nhelm install calico projectcalico/tigera-operator --version v3.26.3 --namespace tigera-operator\n")),(0,r.kt)("p",null,"Or install Calico minimal:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico.yaml\n")),(0,r.kt)("h2",{id:"configure-route53"},"Configure Route53"),(0,r.kt)("p",null,"Follow these steps to use AWS Route53."),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Register a domain and retrieve the Hosted zone ID"),(0,r.kt)("li",{parentName:"ol"},"Create a ",(0,r.kt)("inlineCode",{parentName:"li"},"dns-policy.json")," file for the policy and add the Zone ID:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-json"},'{\n "Version": "2012-10-17",\n "Statement": [\n {\n "Effect": "Allow",\n "Action": "route53:GetChange",\n "Resource": "arn:aws:route53:::change/*"\n },\n {\n "Effect": "Allow",\n "Action": [\n "route53:ChangeResourceRecordSets",\n "route53:ListResourceRecordSets"\n ],\n "Resource": [\n "arn:aws:route53:::hostedzone/"\n ]\n },\n {\n "Effect": "Allow",\n "Action": [\n "route53:ListHostedZonesByName",\n "route53:ListHostedZones"\n ],\n "Resource": [\n "*"\n ]\n }\n ]\n}\n')),(0,r.kt)("ol",{start:3},(0,r.kt)("li",{parentName:"ol"},"Create the policy:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},'aws iam create-policy --policy-name "otomi-dns" --policy-document file://dns-policy.json\n')),(0,r.kt)("ol",{start:4},(0,r.kt)("li",{parentName:"ol"},"export the policy ARN:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"export POLICY_ARN=$(aws iam list-policies --query 'Policies[?PolicyName==``].Arn' --output text)\n")),(0,r.kt)("ol",{start:5},(0,r.kt)("li",{parentName:"ol"},"Create a user:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"USER=user-name\naws iam create-user --user-name $USER\n")),(0,r.kt)("ol",{start:6},(0,r.kt)("li",{parentName:"ol"},"Attach the user to the policy:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"aws iam attach-user-policy --user-name $USER --policy-arn $POLICY_ARN\n")),(0,r.kt)("ol",{start:7},(0,r.kt)("li",{parentName:"ol"},"Create the ",(0,r.kt)("inlineCode",{parentName:"li"},"access-key"),":")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"ACCESS_KEY=$(aws iam create-access-key --user-name $USER)\n")),(0,r.kt)("ol",{start:8},(0,r.kt)("li",{parentName:"ol"},"Get the ",(0,r.kt)("inlineCode",{parentName:"li"},"secret-access-id")," and ",(0,r.kt)("inlineCode",{parentName:"li"},"secret-access-key"),":")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"ACCESS_KEY_ID=$(echo $ACCESS_KEY | jq -r '.AccessKey.AccessKeyId')\nACCESS_KEY_SECRET=$(echo $ACCESS_KEY | jq -r '.AccessKey.SecretAccessKey')\n")),(0,r.kt)("h2",{id:"create-the-valuesyaml-file"},"Create the values.yaml file"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("p",{parentName:"li"},"Get the API server endpoint (eg. ",(0,r.kt)("a",{parentName:"p",href:"https://C000000000000.gr7.eu-central-1.eks.amazonaws.com"},"https://C000000000000.gr7.eu-central-1.eks.amazonaws.com"),")")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("p",{parentName:"li"},"Add the DNS configuration created in the previous step, the API server endpoint, the ",(0,r.kt)("inlineCode",{parentName:"p"},"domainSuffix"),", ",(0,r.kt)("inlineCode",{parentName:"p"},"domainFilters"),", ",(0,r.kt)("inlineCode",{parentName:"p"},"region")," and ",(0,r.kt)("inlineCode",{parentName:"p"},"email")," to the ",(0,r.kt)("inlineCode",{parentName:"p"},"values.yaml")," that we'll use to install Otomi:"))),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"tee values.yaml<{a.d(t,{Zo:()=>p,kt:()=>d});var n=a(7294);function r(e,t,a){return t in e?Object.defineProperty(e,t,{value:a,enumerable:!0,configurable:!0,writable:!0}):e[t]=a,e}function l(e,t){var a=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),a.push.apply(a,n)}return a}function o(e){for(var t=1;t=0||(r[a]=e[a]);return r}(e,t);if(Object.getOwnPropertySymbols){var l=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,a)&&(r[a]=e[a])}return r}var s=n.createContext({}),c=function(e){var t=n.useContext(s),a=t;return e&&(a="function"==typeof e?e(t):o(o({},t),e)),a},p=function(e){var t=c(e.components);return n.createElement(s.Provider,{value:t},e.children)},u={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},m=n.forwardRef((function(e,t){var a=e.components,r=e.mdxType,l=e.originalType,s=e.parentName,p=i(e,["components","mdxType","originalType","parentName"]),m=c(a),d=r,k=m["".concat(s,".").concat(d)]||m[d]||u[d]||l;return a?n.createElement(k,o(o({ref:t},p),{},{components:a})):n.createElement(k,o({ref:t},p))}));function d(e,t){var a=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var l=a.length,o=new Array(l);o[0]=m;var i={};for(var s in t)hasOwnProperty.call(t,s)&&(i[s]=t[s]);i.originalType=e,i.mdxType="string"==typeof e?e:r,o[1]=i;for(var c=2;c{a.r(t),a.d(t,{assets:()=>s,contentTitle:()=>o,default:()=>u,frontMatter:()=>l,metadata:()=>i,toc:()=>c});var n=a(7462),r=(a(7294),a(3905));const l={slug:"aws",title:"AWS",sidebar_label:"AWS"},o="Install Otomi on EKS with DNS using Route53",i={unversionedId:"get-started/installation/aws",id:"get-started/installation/aws",title:"AWS",description:"Prerequisites",source:"@site/docs/get-started/installation/aws.md",sourceDirName:"get-started/installation",slug:"/get-started/installation/aws",permalink:"/docs/get-started/installation/aws",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/tree/main/docs/get-started/installation/aws.md",tags:[],version:"current",frontMatter:{slug:"aws",title:"AWS",sidebar_label:"AWS"},sidebar:"mainSidebar",previous:{title:"Overview",permalink:"/docs/get-started/installation/overview"},next:{title:"Azure",permalink:"/docs/get-started/installation/azure"}},s={},c=[{value:"Prerequisites",id:"prerequisites",level:2},{value:"Additional resources",id:"additional-resources",level:2},{value:"Create an EKS cluster",id:"create-an-eks-cluster",level:2},{value:"Add a CNI",id:"add-a-cni",level:2},{value:"Configure Route53",id:"configure-route53",level:2},{value:"Create the values.yaml file",id:"create-the-valuesyaml-file",level:2},{value:"Install Otomi on EKS",id:"install-otomi-on-eks",level:2}],p={toc:c};function u(e){let{components:t,...a}=e;return(0,r.kt)("wrapper",(0,n.Z)({},p,a,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("h1",{id:"install-otomi-on-eks-with-dns-using-route53"},"Install Otomi on EKS with DNS using Route53"),(0,r.kt)("h2",{id:"prerequisites"},"Prerequisites"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://aws.amazon.com/cli/"},"AWS CLI")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://cloud.google.com/sdk/docs/install"},"Terraform")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://kubernetes.io/docs/tasks/tools/"},"Helm"))),(0,r.kt)("h2",{id:"additional-resources"},"Additional resources"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},"If you use VSCode, hover over variables to see the description/type in .tf and .tfvars files with the ",(0,r.kt)("a",{parentName:"li",href:"https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform"},"Terraform extension")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://learn.hashicorp.com/tutorials/terraform/aws-build"},"How to setup aws cli and terraform"))),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-jsx",metastring:'title="AWS CLI Cheat Sheet"',title:'"AWS',CLI:!0,Cheat:!0,'Sheet"':!0},"# Obtain account\naws sts get-caller-identity\n# Obtain username and userarn\naws iam get-user\n# Obtain rolearn\naws iam list-roles\n# Obtain groups\naws iam list-groups\n")),(0,r.kt)("h2",{id:"create-an-eks-cluster"},"Create an EKS cluster"),(0,r.kt)("p",null,"Clone the Otomi Terraform repository:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"git clone https://github.com/redkubes/quickstart.git\ncd eks\n")),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},"Copy ",(0,r.kt)("inlineCode",{parentName:"li"},"example.tfvars")," file to ",(0,r.kt)("inlineCode",{parentName:"li"},"terraform.tfvars")," file and fill in missing configuration parameters"),(0,r.kt)("li",{parentName:"ul"},"Open a terminal and run the following:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"terraform init\n# install the EKS cluster\nterraform apply\n")),(0,r.kt)("p",null,"Get the credentials of the cluster:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"# Update your kubeconfig\n# Default: aws eks update-kubeconfig --name otomi\naws eks update-kubeconfig --name \n")),(0,r.kt)("h2",{id:"add-a-cni"},"Add a CNI"),(0,r.kt)("p",null,"To use the network policies feature in Otomi, make sure to install the ",(0,r.kt)("a",{parentName:"p",href:"https://www.tigera.io/project-calico/"},"Calico")," CNI or any other CNI that supports Kubernetes network polices."),(0,r.kt)("p",null,"Install Tigera Operator:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"helm repo add projectcalico https://docs.tigera.io/calico/charts\nhelm repo update\nkubectl create namespace tigera-operator\nhelm install calico projectcalico/tigera-operator --version v3.26.3 --namespace tigera-operator\n")),(0,r.kt)("p",null,"Or install Calico minimal:"),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico.yaml\n")),(0,r.kt)("h2",{id:"configure-route53"},"Configure Route53"),(0,r.kt)("p",null,"Follow these steps to use AWS Route53."),(0,r.kt)("ol",null,(0,r.kt)("li",{parentName:"ol"},"Register a domain and retrieve the Hosted zone ID"),(0,r.kt)("li",{parentName:"ol"},"Create a ",(0,r.kt)("inlineCode",{parentName:"li"},"dns-policy.json")," file for the policy and add the Zone ID:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-json"},'{\n "Version": "2012-10-17",\n "Statement": [\n {\n "Effect": "Allow",\n "Action": "route53:GetChange",\n "Resource": "arn:aws:route53:::change/*"\n },\n {\n "Effect": "Allow",\n "Action": [\n "route53:ChangeResourceRecordSets",\n "route53:ListResourceRecordSets"\n ],\n "Resource": [\n "arn:aws:route53:::hostedzone/"\n ]\n },\n {\n "Effect": "Allow",\n "Action": [\n "route53:ListHostedZonesByName",\n "route53:ListHostedZones"\n ],\n "Resource": [\n "*"\n ]\n }\n ]\n}\n')),(0,r.kt)("ol",{start:3},(0,r.kt)("li",{parentName:"ol"},"Create the policy:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},'aws iam create-policy --policy-name "otomi-dns" --policy-document file://dns-policy.json\n')),(0,r.kt)("ol",{start:4},(0,r.kt)("li",{parentName:"ol"},"export the policy ARN:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"export POLICY_ARN=$(aws iam list-policies --query 'Policies[?PolicyName==``].Arn' --output text)\n")),(0,r.kt)("ol",{start:5},(0,r.kt)("li",{parentName:"ol"},"Create a user:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"USER=user-name\naws iam create-user --user-name $USER\n")),(0,r.kt)("ol",{start:6},(0,r.kt)("li",{parentName:"ol"},"Attach the user to the policy:")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"aws iam attach-user-policy --user-name $USER --policy-arn $POLICY_ARN\n")),(0,r.kt)("ol",{start:7},(0,r.kt)("li",{parentName:"ol"},"Create the ",(0,r.kt)("inlineCode",{parentName:"li"},"access-key"),":")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"ACCESS_KEY=$(aws iam create-access-key --user-name $USER)\n")),(0,r.kt)("ol",{start:8},(0,r.kt)("li",{parentName:"ol"},"Get the ",(0,r.kt)("inlineCode",{parentName:"li"},"secret-access-id")," and ",(0,r.kt)("inlineCode",{parentName:"li"},"secret-access-key"),":")),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"ACCESS_KEY_ID=$(echo $ACCESS_KEY | jq -r '.AccessKey.AccessKeyId')\nACCESS_KEY_SECRET=$(echo $ACCESS_KEY | jq -r '.AccessKey.SecretAccessKey')\n")),(0,r.kt)("h2",{id:"create-the-valuesyaml-file"},"Create the values.yaml file"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("p",{parentName:"li"},"Get the API server endpoint. You can find the API server endpoint in the Details section of the cluster in the AWS console.")),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("p",{parentName:"li"},"Add the DNS configuration created in the previous step, the API server endpoint, the ",(0,r.kt)("inlineCode",{parentName:"p"},"domainSuffix"),", ",(0,r.kt)("inlineCode",{parentName:"p"},"domainFilters"),", ",(0,r.kt)("inlineCode",{parentName:"p"},"region")," and ",(0,r.kt)("inlineCode",{parentName:"p"},"email")," to the ",(0,r.kt)("inlineCode",{parentName:"p"},"values.yaml")," that we'll use to install Otomi:"))),(0,r.kt)("pre",null,(0,r.kt)("code",{parentName:"pre",className:"language-bash"},"tee values.yaml<{n.d(t,{Zo:()=>u,kt:()=>d});var a=n(7294);function o(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function r(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);t&&(a=a.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,a)}return n}function i(e){for(var t=1;t=0||(o[n]=e[n]);return o}(e,t);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(a=0;a=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(o[n]=e[n])}return o}var l=a.createContext({}),c=function(e){var t=a.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},u=function(e){var t=c(e.components);return a.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return a.createElement(a.Fragment,{},t)}},m=a.forwardRef((function(e,t){var n=e.components,o=e.mdxType,r=e.originalType,l=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),m=c(n),d=o,h=m["".concat(l,".").concat(d)]||m[d]||p[d]||r;return n?a.createElement(h,i(i({ref:t},u),{},{components:n})):a.createElement(h,i({ref:t},u))}));function d(e,t){var n=arguments,o=t&&t.mdxType;if("string"==typeof e||o){var r=n.length,i=new Array(r);i[0]=m;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:o,i[1]=s;for(var c=2;c{n.r(t),n.d(t,{assets:()=>l,contentTitle:()=>i,default:()=>p,frontMatter:()=>r,metadata:()=>s,toc:()=>c});var a=n(7462),o=(n(7294),n(3905));const r={slug:"multi-tenancy",title:"Multi-tenancy",sidebar_label:"Multi-tenancy"},i=void 0,s={unversionedId:"use-cases/multi-tenancy",id:"use-cases/multi-tenancy",title:"Multi-tenancy",description:"Introduction",source:"@site/product/use-cases/multi-tenancy.md",sourceDirName:"use-cases",slug:"/use-cases/multi-tenancy",permalink:"/product/use-cases/multi-tenancy",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/multi-tenancy.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"multi-tenancy",title:"Multi-tenancy",sidebar_label:"Multi-tenancy"},sidebar:"mainSidebar",previous:{title:"Adoption Framework",permalink:"/product/use-cases/adoption-framework"},next:{title:"CI/CD",permalink:"/product/use-cases/ci-cd"}},l={},c=[{value:"Introduction",id:"introduction",level:2},{value:"Multi-tenancy in Otomi",id:"multi-tenancy-in-otomi",level:2},{value:"Why multi-tenancy in Otomi?",id:"why-multi-tenancy-in-otomi",level:2},{value:"Prevent cluster sprawl",id:"prevent-cluster-sprawl",level:3},{value:"Fast onboarding of multiple tenants",id:"fast-onboarding-of-multiple-tenants",level:3}],u={toc:c};function p(e){let{components:t,...r}=e;return(0,o.kt)("wrapper",(0,a.Z)({},u,r,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h2",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,'Multi-tenant Kubernetes clusters are shared by multiple users and/or workloads which are referred to as "tenants". Operators most commonly implement resource isolation in Kubernetes, using namespaces and resource quota.'),(0,o.kt)("p",null,"The most common use cases for implementing multi-tenancy are:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://kubernetes.io/docs/concepts/security/multi-tenancy/#multiple-teams"},"Multiple teams")," (within an organization) share a single cluster"),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://kubernetes.io/docs/concepts/security/multi-tenancy/#multiple-customers"},"Multiple customers")," share a single cluster")),(0,o.kt)("p",null,"Probably the most known tools to implement multi-tenancy are ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/clastix/capsule"},"Capsule")," and ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/loft-sh/kiosk"},"Kiosk"),". But these tools only implement multi-tenancy on cluster API level. What they don't offer is multi-tenant and role based access to shared tools on the cluster like Harbor, Vault, Git, and Argo CD. They also don't provide isolation for container logs and custom metrics."),(0,o.kt)("p",null,"So what if you would like to offer teams or customers not only access to the Kubernetes API, but also to (automatically provisioned) access to a Git repo, a private docker registry, a space in Vault to create and manage secrets, Argo CD, a private Prometheus instance, isolated log aggregation? This is where Otomi steps in."),(0,o.kt)("h2",{id:"multi-tenancy-in-otomi"},"Multi-tenancy in Otomi"),(0,o.kt)("p",null,"Otomi goes a step higher up in the stack. Otomi does not only provide multi-tenancy on the K8s API level, but also for shared tools on the cluster. "),(0,o.kt)("p",null,(0,o.kt)("img",{alt:"multi-tenancy",src:n(1998).Z,width:"2025",height:"1465"})),(0,o.kt)("p",null,"When multi-tenancy in Otomi is activated (which is optional), Otomi will support the following features:"),(0,o.kt)("ol",null,(0,o.kt)("li",{parentName:"ol"},"Teams are provided with a dedicated Prometheus instance for custom metrics (for metrics that should not be accessible for other tenants)"),(0,o.kt)("li",{parentName:"ol"},"Teams are provided with a dedicated Grafana instance configured with authorization, allowing only authenticated tenant members to access tenant dashboards"),(0,o.kt)("li",{parentName:"ol"},"Container logs are separated in Loki combined with authorization, allowing only authenticated tenant members access to the tenants container logs"),(0,o.kt)("li",{parentName:"ol"},"When Harbor is enabled, tenants will get access to a tenant project, allowing only authenticated tenant members to access tenant registries"),(0,o.kt)("li",{parentName:"ol"},"When Vault is enabled, tenant will get access to a space in Vault, allowing only authenticated tenant members access to tenant secrets"),(0,o.kt)("li",{parentName:"ol"},"When ArgoCD is enabled, tenants can only see the tenants ArgoCD applications created by Otomi"),(0,o.kt)("li",{parentName:"ol"},"Tenants will get access to Gitea and can create their own Git repositories"),(0,o.kt)("li",{parentName:"ol"},"Tenant namespaces are by default isolated for ingress and egress network traffic"),(0,o.kt)("li",{parentName:"ol"},"Tenants can allow other tenants to access their services"),(0,o.kt)("li",{parentName:"ol"},"Tenant services that are publicly exposed can be configured with OIDC, only allowing tenant members to access the exposed services")),(0,o.kt)("h2",{id:"why-multi-tenancy-in-otomi"},"Why multi-tenancy in Otomi?"),(0,o.kt)("h3",{id:"prevent-cluster-sprawl"},"Prevent cluster sprawl"),(0,o.kt)("p",null,"As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work."),(0,o.kt)("p",null,"With Otomi you can support multi-tenancy, allowing multiple tenants (like multiple development teams) to work independently on the same cluster, while sharing all the tools. Now you only have to deploy a single development cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl."),(0,o.kt)("h3",{id:"fast-onboarding-of-multiple-tenants"},"Fast onboarding of multiple tenants"),(0,o.kt)("p",null,"When a new project starts, or when a new development team would like to start using Kubernetes, onboarding usually takes a lot of time. It's not only about providing development teams access to a Kubernetes namespace. No, developers also need access to an image registry, container logs, container metrics, alerts, secrets stores, container vulnerability reports and policy compliance reports."),(0,o.kt)("p",null,"With Otomi you can onboard development teams (tenants) in just a couple of minutes, allowing them to login to the self-service portal and:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Get access to a private image registry"),(0,o.kt)("li",{parentName:"ul"},"Download the Docker login credentials to get access to their private image registry"),(0,o.kt)("li",{parentName:"ul"},"Build OCI-compliant images from application code"),(0,o.kt)("li",{parentName:"ul"},"Deploy images (stored in the private registry) using the Otomi workloads feature"),(0,o.kt)("li",{parentName:"ul"},"Get access to pre-configured dashboards to see container metrics, policy violations, detected threads in containers and detected vulnerabilities in containers"),(0,o.kt)("li",{parentName:"ul"},"Configure ingress and network policies"),(0,o.kt)("li",{parentName:"ul"},"Configure HTTP response headers"),(0,o.kt)("li",{parentName:"ul"},"Configure CNAMEs"),(0,o.kt)("li",{parentName:"ul"},"Get access to Vault to create and manage secrets"),(0,o.kt)("li",{parentName:"ul"},"Use secrets for ingress or workloads")),(0,o.kt)("p",null,"When a team already has a code repo with a Dockderfile, they can build, deploy and expose this app within minutes after they have been onboarded onto the platform."))}p.isMDXComponent=!0},1998:(e,t,n)=>{n.d(t,{Z:()=>a});const a=n.p+"assets/images/multi-tenancy-6d20d20cfd471ce025aa59ca8b3498bf.png"}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[8185],{3905:(e,t,n)=>{n.d(t,{Zo:()=>u,kt:()=>d});var a=n(7294);function o(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function r(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);t&&(a=a.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,a)}return n}function i(e){for(var t=1;t=0||(o[n]=e[n]);return o}(e,t);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(a=0;a=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(o[n]=e[n])}return o}var l=a.createContext({}),c=function(e){var t=a.useContext(l),n=t;return e&&(n="function"==typeof e?e(t):i(i({},t),e)),n},u=function(e){var t=c(e.components);return a.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return a.createElement(a.Fragment,{},t)}},m=a.forwardRef((function(e,t){var n=e.components,o=e.mdxType,r=e.originalType,l=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),m=c(n),d=o,h=m["".concat(l,".").concat(d)]||m[d]||p[d]||r;return n?a.createElement(h,i(i({ref:t},u),{},{components:n})):a.createElement(h,i({ref:t},u))}));function d(e,t){var n=arguments,o=t&&t.mdxType;if("string"==typeof e||o){var r=n.length,i=new Array(r);i[0]=m;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:o,i[1]=s;for(var c=2;c{n.r(t),n.d(t,{assets:()=>l,contentTitle:()=>i,default:()=>p,frontMatter:()=>r,metadata:()=>s,toc:()=>c});var a=n(7462),o=(n(7294),n(3905));const r={slug:"multi-tenancy",title:"Multi-tenancy",sidebar_label:"Multi-tenancy"},i=void 0,s={unversionedId:"use-cases/multi-tenancy",id:"use-cases/multi-tenancy",title:"Multi-tenancy",description:"Introduction",source:"@site/product/use-cases/multi-tenancy.md",sourceDirName:"use-cases",slug:"/use-cases/multi-tenancy",permalink:"/product/use-cases/multi-tenancy",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/multi-tenancy.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"multi-tenancy",title:"Multi-tenancy",sidebar_label:"Multi-tenancy"},sidebar:"mainSidebar",previous:{title:"Adoption Framework",permalink:"/product/use-cases/adoption-framework"},next:{title:"CI/CD",permalink:"/product/use-cases/ci-cd"}},l={},c=[{value:"Introduction",id:"introduction",level:2},{value:"Multi-tenancy in Otomi",id:"multi-tenancy-in-otomi",level:2},{value:"Why multi-tenancy in Otomi?",id:"why-multi-tenancy-in-otomi",level:2},{value:"Prevent cluster sprawl",id:"prevent-cluster-sprawl",level:3},{value:"Fast onboarding of multiple tenants",id:"fast-onboarding-of-multiple-tenants",level:3}],u={toc:c};function p(e){let{components:t,...r}=e;return(0,o.kt)("wrapper",(0,a.Z)({},u,r,{components:t,mdxType:"MDXLayout"}),(0,o.kt)("h2",{id:"introduction"},"Introduction"),(0,o.kt)("p",null,'Multi-tenant Kubernetes clusters are shared by multiple users and/or workloads which are referred to as "tenants". Operators most commonly implement resource isolation in Kubernetes, using namespaces and resource quota.'),(0,o.kt)("p",null,"The most common use cases for implementing multi-tenancy are:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://kubernetes.io/docs/concepts/security/multi-tenancy/#multiple-teams"},"Multiple teams")," (within an organization) share a single cluster"),(0,o.kt)("li",{parentName:"ul"},(0,o.kt)("a",{parentName:"li",href:"https://kubernetes.io/docs/concepts/security/multi-tenancy/#multiple-customers"},"Multiple customers")," share a single cluster")),(0,o.kt)("p",null,"Probably the most known tools to implement multi-tenancy are ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/clastix/capsule"},"Capsule")," and ",(0,o.kt)("a",{parentName:"p",href:"https://github.com/loft-sh/kiosk"},"Kiosk"),". But these tools only implement multi-tenancy on cluster API level. What they don't offer is multi-tenant and role based access to shared tools on the cluster like Harbor, Vault, Git, and Argo CD. They also don't provide isolation for container logs and custom metrics."),(0,o.kt)("p",null,"So what if you would like to offer teams or customers not only access to the Kubernetes API, but also to (automatically provisioned) access to a Git repo, a private docker registry, a space in Vault to create and manage secrets, Argo CD, a private Prometheus instance, isolated log aggregation? This is where Otomi steps in."),(0,o.kt)("h2",{id:"multi-tenancy-in-otomi"},"Multi-tenancy in Otomi"),(0,o.kt)("p",null,"Otomi goes a step higher up in the stack. Otomi does not only provide multi-tenancy on the K8s API level, but also for shared tools on the cluster. "),(0,o.kt)("p",null,(0,o.kt)("img",{alt:"multi-tenancy",src:n(1998).Z,width:"2025",height:"1465"})),(0,o.kt)("p",null,"When multi-tenancy in Otomi is activated (which is optional), Otomi will support the following features:"),(0,o.kt)("ol",null,(0,o.kt)("li",{parentName:"ol"},"Teams are provided with a dedicated Prometheus instance for custom metrics (for metrics that should not be accessible for other tenants)"),(0,o.kt)("li",{parentName:"ol"},"Teams are provided with a dedicated Grafana instance configured with authorization, allowing only authenticated tenant members to access tenant dashboards"),(0,o.kt)("li",{parentName:"ol"},"Container logs are separated in Loki combined with authorization, allowing only authenticated tenant members access to the tenants container logs"),(0,o.kt)("li",{parentName:"ol"},"When Harbor is enabled, tenants will get access to a tenant project, allowing only authenticated tenant members to access tenant registries"),(0,o.kt)("li",{parentName:"ol"},"When Vault is enabled, tenant will get access to a space in Vault, allowing only authenticated tenant members access to tenant secrets"),(0,o.kt)("li",{parentName:"ol"},"When ArgoCD is enabled, tenants can only see the tenants ArgoCD applications created by Otomi"),(0,o.kt)("li",{parentName:"ol"},"Tenants will get access to Gitea and can create their own Git repositories"),(0,o.kt)("li",{parentName:"ol"},"Tenant namespaces are by default isolated for ingress and egress network traffic"),(0,o.kt)("li",{parentName:"ol"},"Tenants can allow other tenants to access their services"),(0,o.kt)("li",{parentName:"ol"},"Tenant services that are publicly exposed can be configured with OIDC, only allowing tenant members to access the exposed services")),(0,o.kt)("h2",{id:"why-multi-tenancy-in-otomi"},"Why multi-tenancy in Otomi?"),(0,o.kt)("h3",{id:"prevent-cluster-sprawl"},"Prevent cluster sprawl"),(0,o.kt)("p",null,"As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work."),(0,o.kt)("p",null,"With Otomi you can support multi-tenancy, allowing multiple tenants (like multiple development teams) to work independently on the same cluster, while sharing all the tools. Now you only have to deploy a single development cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl."),(0,o.kt)("h3",{id:"fast-onboarding-of-multiple-tenants"},"Fast onboarding of multiple tenants"),(0,o.kt)("p",null,"When a new project starts, or when a new development team would like to start using Kubernetes, onboarding usually takes a lot of time. It's not only about providing development teams access to a Kubernetes namespace. No, developers also need access to an image registry, container logs, container metrics, alerts, secrets stores, container vulnerability reports and policy compliance reports."),(0,o.kt)("p",null,"With Otomi you can onboard development teams (tenants) in just a couple of minutes, allowing them to login to the self-service portal and:"),(0,o.kt)("ul",null,(0,o.kt)("li",{parentName:"ul"},"Get access to a private image registry"),(0,o.kt)("li",{parentName:"ul"},"Download the Docker login credentials to get access to their private image registry"),(0,o.kt)("li",{parentName:"ul"},"Build OCI-compliant images from application code"),(0,o.kt)("li",{parentName:"ul"},"Deploy images (stored in the private registry) using the Otomi workloads feature"),(0,o.kt)("li",{parentName:"ul"},"Get access to pre-configured dashboards to see container metrics, policy violations, detected threads in containers and detected vulnerabilities in containers"),(0,o.kt)("li",{parentName:"ul"},"Configure ingress and network policies"),(0,o.kt)("li",{parentName:"ul"},"Configure HTTP response headers"),(0,o.kt)("li",{parentName:"ul"},"Configure CNAMEs"),(0,o.kt)("li",{parentName:"ul"},"Get access to Vault to create and manage secrets"),(0,o.kt)("li",{parentName:"ul"},"Use secrets for ingress or workloads")),(0,o.kt)("p",null,"When a team already has a code repo with a Dockderfile, they can build, deploy and expose this app within minutes after they have been onboarded onto the platform."))}p.isMDXComponent=!0},1998:(e,t,n)=>{n.d(t,{Z:()=>a});const a=n.p+"assets/images/multi-tenancy-6d20d20cfd471ce025aa59ca8b3498bf.png"}}]); \ No newline at end of file diff --git a/assets/js/b4b7b186.4ab79471.js b/assets/js/b4b7b186.0e2a4edc.js similarity index 98% rename from assets/js/b4b7b186.4ab79471.js rename to assets/js/b4b7b186.0e2a4edc.js index f9c125b4c..df5d6f160 100644 --- a/assets/js/b4b7b186.4ab79471.js +++ b/assets/js/b4b7b186.0e2a4edc.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[3520],{3905:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>v});var n=r(7294);function a(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function i(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,n)}return r}function o(e){for(var t=1;t=0||(a[r]=e[r]);return a}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(a[r]=e[r])}return a}var l=n.createContext({}),u=function(e){var t=n.useContext(l),r=t;return e&&(r="function"==typeof e?e(t):o(o({},t),e)),r},c=function(e){var t=u(e.components);return n.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},d=n.forwardRef((function(e,t){var r=e.components,a=e.mdxType,i=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),d=u(r),v=a,m=d["".concat(l,".").concat(v)]||d[v]||p[v]||i;return r?n.createElement(m,o(o({ref:t},c),{},{components:r})):n.createElement(m,o({ref:t},c))}));function v(e,t){var r=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var i=r.length,o=new Array(i);o[0]=d;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:a,o[1]=s;for(var u=2;u{r.r(t),r.d(t,{assets:()=>l,contentTitle:()=>o,default:()=>p,frontMatter:()=>i,metadata:()=>s,toc:()=>u});var n=r(7462),a=(r(7294),r(3905));const i={slug:"serverless",title:"Serverless",sidebar_label:"Serverless"},o=void 0,s={unversionedId:"use-cases/serverless",id:"use-cases/serverless",title:"Serverless",description:"Introduction",source:"@site/product/use-cases/serverless.md",sourceDirName:"use-cases",slug:"/use-cases/serverless",permalink:"/product/use-cases/serverless",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/serverless.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"serverless",title:"Serverless",sidebar_label:"Serverless"},sidebar:"mainSidebar",previous:{title:"CI/CD",permalink:"/product/use-cases/ci-cd"},next:{title:"EULA",permalink:"/product/eula/v1"}},l={},u=[{value:"Introduction",id:"introduction",level:2},{value:"Creating Knative services",id:"creating-knative-services",level:2},{value:"Migrating Lambda functions to Knative",id:"migrating-lambda-functions-to-knative",level:2}],c={toc:u};function p(e){let{components:t,...r}=e;return(0,a.kt)("wrapper",(0,n.Z)({},c,r,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h2",{id:"introduction"},"Introduction"),(0,a.kt)("p",null,"Knative is a platform that provides tools for deploying, running, and managing ",(0,a.kt)("strong",{parentName:"p"},"serverless")," cloud-native applications to Kubernetes. Knative brings together the scalability of Kubernetes and ease of development of serverless applications, giving you more control over the resources, and allowing you to focus on the application without worrying about the infrastructure."),(0,a.kt)("p",null,"Otomi includes Knative Serving as an optional tool. Otomi installs and configures the correct version of Knative based on the used Kubernetes version and integrates Knative into the Otomi ingress architecture. All you need to do after activating Knative is to deploy a Knative service."),(0,a.kt)("h2",{id:"creating-knative-services"},"Creating Knative services"),(0,a.kt)("p",null,"There are 3 ways to deploy Knative serverless workloads in Otomi:"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},"Create a raw Knative service manifest and add it to the teams ",(0,a.kt)("inlineCode",{parentName:"li"},"-argocd")," repository"),(0,a.kt)("li",{parentName:"ol"},"Create a Otomi serverless workload"),(0,a.kt)("li",{parentName:"ol"},"Create a Otomi workload with a custom (BYO) Helm chart")),(0,a.kt)("h2",{id:"migrating-lambda-functions-to-knative"},"Migrating Lambda functions to Knative"),(0,a.kt)("p",null,"A great way to migrate AWS Lambda functions to Kubernetes/Knative is to use ",(0,a.kt)("a",{parentName:"p",href:"https://github.com/triggermesh/knative-lambda-runtime"},"Triggermesh KLR"),". KLR (pronounced clear) are Tekton Tasks that can be used to run an AWS Lambda function in a Kubernetes cluster installed with Knative."),(0,a.kt)("p",null,"Steps:"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},"Activate Knative and Argo CD in Otomi"),(0,a.kt)("li",{parentName:"ol"},"Create a Dockerfile, extracting the desired ",(0,a.kt)("a",{parentName:"li",href:"https://github.com/triggermesh/knative-lambda-runtime#run-in-docker"},"runtime")),(0,a.kt)("li",{parentName:"ol"},"Build and push the image (to the private repository in Harbor)"),(0,a.kt)("li",{parentName:"ol"},"Create a Knative service using the Otomi workload feature"),(0,a.kt)("li",{parentName:"ol"},"Expose the service publicly using the Otomi services feature")))}p.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[3520],{3905:(e,t,r)=>{r.d(t,{Zo:()=>c,kt:()=>v});var n=r(7294);function a(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function i(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,n)}return r}function o(e){for(var t=1;t=0||(a[r]=e[r]);return a}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(a[r]=e[r])}return a}var l=n.createContext({}),u=function(e){var t=n.useContext(l),r=t;return e&&(r="function"==typeof e?e(t):o(o({},t),e)),r},c=function(e){var t=u(e.components);return n.createElement(l.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},d=n.forwardRef((function(e,t){var r=e.components,a=e.mdxType,i=e.originalType,l=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),d=u(r),v=a,m=d["".concat(l,".").concat(v)]||d[v]||p[v]||i;return r?n.createElement(m,o(o({ref:t},c),{},{components:r})):n.createElement(m,o({ref:t},c))}));function v(e,t){var r=arguments,a=t&&t.mdxType;if("string"==typeof e||a){var i=r.length,o=new Array(i);o[0]=d;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:a,o[1]=s;for(var u=2;u{r.r(t),r.d(t,{assets:()=>l,contentTitle:()=>o,default:()=>p,frontMatter:()=>i,metadata:()=>s,toc:()=>u});var n=r(7462),a=(r(7294),r(3905));const i={slug:"serverless",title:"Serverless",sidebar_label:"Serverless"},o=void 0,s={unversionedId:"use-cases/serverless",id:"use-cases/serverless",title:"Serverless",description:"Introduction",source:"@site/product/use-cases/serverless.md",sourceDirName:"use-cases",slug:"/use-cases/serverless",permalink:"/product/use-cases/serverless",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/serverless.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"serverless",title:"Serverless",sidebar_label:"Serverless"},sidebar:"mainSidebar",previous:{title:"CI/CD",permalink:"/product/use-cases/ci-cd"},next:{title:"EULA",permalink:"/product/eula/v1"}},l={},u=[{value:"Introduction",id:"introduction",level:2},{value:"Creating Knative services",id:"creating-knative-services",level:2},{value:"Migrating Lambda functions to Knative",id:"migrating-lambda-functions-to-knative",level:2}],c={toc:u};function p(e){let{components:t,...r}=e;return(0,a.kt)("wrapper",(0,n.Z)({},c,r,{components:t,mdxType:"MDXLayout"}),(0,a.kt)("h2",{id:"introduction"},"Introduction"),(0,a.kt)("p",null,"Knative is a platform that provides tools for deploying, running, and managing ",(0,a.kt)("strong",{parentName:"p"},"serverless")," cloud-native applications to Kubernetes. Knative brings together the scalability of Kubernetes and ease of development of serverless applications, giving you more control over the resources, and allowing you to focus on the application without worrying about the infrastructure."),(0,a.kt)("p",null,"Otomi includes Knative Serving as an optional tool. Otomi installs and configures the correct version of Knative based on the used Kubernetes version and integrates Knative into the Otomi ingress architecture. All you need to do after activating Knative is to deploy a Knative service."),(0,a.kt)("h2",{id:"creating-knative-services"},"Creating Knative services"),(0,a.kt)("p",null,"There are 3 ways to deploy Knative serverless workloads in Otomi:"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},"Create a raw Knative service manifest and add it to the teams ",(0,a.kt)("inlineCode",{parentName:"li"},"-argocd")," repository"),(0,a.kt)("li",{parentName:"ol"},"Create a Otomi serverless workload"),(0,a.kt)("li",{parentName:"ol"},"Create a Otomi workload with a custom (BYO) Helm chart")),(0,a.kt)("h2",{id:"migrating-lambda-functions-to-knative"},"Migrating Lambda functions to Knative"),(0,a.kt)("p",null,"A great way to migrate AWS Lambda functions to Kubernetes/Knative is to use ",(0,a.kt)("a",{parentName:"p",href:"https://github.com/triggermesh/knative-lambda-runtime"},"Triggermesh KLR"),". KLR (pronounced clear) are Tekton Tasks that can be used to run an AWS Lambda function in a Kubernetes cluster installed with Knative."),(0,a.kt)("p",null,"Steps:"),(0,a.kt)("ol",null,(0,a.kt)("li",{parentName:"ol"},"Activate Knative and Argo CD in Otomi"),(0,a.kt)("li",{parentName:"ol"},"Create a Dockerfile, extracting the desired ",(0,a.kt)("a",{parentName:"li",href:"https://github.com/triggermesh/knative-lambda-runtime#run-in-docker"},"runtime")),(0,a.kt)("li",{parentName:"ol"},"Build and push the image (to the private repository in Harbor)"),(0,a.kt)("li",{parentName:"ol"},"Create a Knative service using the Otomi workload feature"),(0,a.kt)("li",{parentName:"ol"},"Expose the service publicly using the Otomi services feature")))}p.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/c1cd9779.f2b1173b.js b/assets/js/c1cd9779.f594a6c7.js similarity index 99% rename from assets/js/c1cd9779.f2b1173b.js rename to assets/js/c1cd9779.f594a6c7.js index 8fbc5502b..966e6342c 100644 --- a/assets/js/c1cd9779.f2b1173b.js +++ b/assets/js/c1cd9779.f594a6c7.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[1658],{3905:(e,t,n)=>{n.d(t,{Zo:()=>u,kt:()=>m});var o=n(7294);function i(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function a(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);t&&(o=o.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,o)}return n}function r(e){for(var t=1;t=0||(i[n]=e[n]);return i}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(i[n]=e[n])}return i}var s=o.createContext({}),c=function(e){var t=o.useContext(s),n=t;return e&&(n="function"==typeof e?e(t):r(r({},t),e)),n},u=function(e){var t=c(e.components);return o.createElement(s.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return o.createElement(o.Fragment,{},t)}},d=o.forwardRef((function(e,t){var n=e.components,i=e.mdxType,a=e.originalType,s=e.parentName,u=l(e,["components","mdxType","originalType","parentName"]),d=c(n),m=i,f=d["".concat(s,".").concat(m)]||d[m]||p[m]||a;return n?o.createElement(f,r(r({ref:t},u),{},{components:n})):o.createElement(f,r({ref:t},u))}));function m(e,t){var n=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var a=n.length,r=new Array(a);r[0]=d;var l={};for(var s in t)hasOwnProperty.call(t,s)&&(l[s]=t[s]);l.originalType=e,l.mdxType="string"==typeof e?e:i,r[1]=l;for(var c=2;c{n.r(t),n.d(t,{assets:()=>s,contentTitle:()=>r,default:()=>p,frontMatter:()=>a,metadata:()=>l,toc:()=>c});var o=n(7462),i=(n(7294),n(3905));const a={slug:"code-of-conduct",title:"Code of Conduct",sidebar_label:"Code of Conduct"},r=void 0,l={unversionedId:"code-of-conduct",id:"code-of-conduct",title:"Code of Conduct",description:"Our Pledge",source:"@site/community/code-of-conduct.md",sourceDirName:".",slug:"/code-of-conduct",permalink:"/community/code-of-conduct",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/code-of-conduct.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"code-of-conduct",title:"Code of Conduct",sidebar_label:"Code of Conduct"},sidebar:"mainSidebar",previous:{title:"Values",permalink:"/community/community-values"},next:{title:"Expectations",permalink:"/community/expectations"}},s={},c=[{value:"Our Pledge",id:"our-pledge",level:2},{value:"Our Standards",id:"our-standards",level:2},{value:"Enforcement Responsibilities",id:"enforcement-responsibilities",level:2},{value:"Scope",id:"scope",level:2},{value:"Enforcement",id:"enforcement",level:2},{value:"Enforcement Guidelines",id:"enforcement-guidelines",level:2},{value:"1. Correction",id:"1-correction",level:3},{value:"2. Warning",id:"2-warning",level:3},{value:"3. Temporary Ban",id:"3-temporary-ban",level:3},{value:"4. Permanent Ban",id:"4-permanent-ban",level:3},{value:"Attribution",id:"attribution",level:2}],u={toc:c};function p(e){let{components:t,...n}=e;return(0,i.kt)("wrapper",(0,o.Z)({},u,n,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"our-pledge"},"Our Pledge"),(0,i.kt)("p",null,"We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation."),(0,i.kt)("p",null,"We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community."),(0,i.kt)("h2",{id:"our-standards"},"Our Standards"),(0,i.kt)("p",null,"Examples of behavior that contributes to a positive environment for our community include:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Demonstrating empathy and kindness toward other people"),(0,i.kt)("li",{parentName:"ul"},"Being respectful of differing opinions, viewpoints, and experiences"),(0,i.kt)("li",{parentName:"ul"},"Giving and gracefully accepting constructive feedback"),(0,i.kt)("li",{parentName:"ul"},"Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience"),(0,i.kt)("li",{parentName:"ul"},"Focusing on what is best not just for us as individuals, but for the overall community")),(0,i.kt)("p",null,"Examples of unacceptable behavior include:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"The use of sexualized language or imagery, and sexual attention or advances of any kind"),(0,i.kt)("li",{parentName:"ul"},"Trolling, insulting or derogatory comments, and personal or political attacks"),(0,i.kt)("li",{parentName:"ul"},"Public or private harassment"),(0,i.kt)("li",{parentName:"ul"},"Publishing others' private information, such as a physical or email address, without their explicit permission"),(0,i.kt)("li",{parentName:"ul"},"Other conduct which could reasonably be considered inappropriate in a professional setting")),(0,i.kt)("h2",{id:"enforcement-responsibilities"},"Enforcement Responsibilities"),(0,i.kt)("p",null,"Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful."),(0,i.kt)("p",null,"Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate."),(0,i.kt)("h2",{id:"scope"},"Scope"),(0,i.kt)("p",null,"This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event."),(0,i.kt)("h2",{id:"enforcement"},"Enforcement"),(0,i.kt)("p",null,"Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at ",(0,i.kt)("a",{parentName:"p",href:"mailto:community@redkubes.com."},"community@redkubes.com.")," All complaints will be reviewed and investigated promptly and fairly."),(0,i.kt)("p",null,"All community leaders are obligated to respect the privacy and security of the reporter of any incident."),(0,i.kt)("h2",{id:"enforcement-guidelines"},"Enforcement Guidelines"),(0,i.kt)("p",null,"Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:"),(0,i.kt)("h3",{id:"1-correction"},"1. Correction"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested."),(0,i.kt)("h3",{id:"2-warning"},"2. Warning"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": A violation through a single incident or series of actions."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban."),(0,i.kt)("h3",{id:"3-temporary-ban"},"3. Temporary Ban"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": A serious violation of community standards, including sustained inappropriate behavior."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban."),(0,i.kt)("h3",{id:"4-permanent-ban"},"4. Permanent Ban"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A permanent ban from any sort of public interaction within the community."),(0,i.kt)("h2",{id:"attribution"},"Attribution"),(0,i.kt)("p",null,"This Code of Conduct is adapted from the ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org"},"Contributor Covenant"),", version 2.0, available at ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org/version/2/0/code_of_conduct.html"},"v2.0"),"."),(0,i.kt)("p",null,"Community Impact Guidelines were inspired by ",(0,i.kt)("a",{parentName:"p",href:"https://github.com/mozilla/diversity"},"Mozilla's code of conduct enforcement ladder"),"."),(0,i.kt)("p",null,"For answers to common questions about this code of conduct, see the FAQ at ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org/faq"},"https://www.contributor-covenant.org/faq"),". Translations are available at ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org/translations"},"https://www.contributor-covenant.org/translations"),"."))}p.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[1658],{3905:(e,t,n)=>{n.d(t,{Zo:()=>u,kt:()=>m});var o=n(7294);function i(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function a(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);t&&(o=o.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,o)}return n}function r(e){for(var t=1;t=0||(i[n]=e[n]);return i}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(i[n]=e[n])}return i}var s=o.createContext({}),c=function(e){var t=o.useContext(s),n=t;return e&&(n="function"==typeof e?e(t):r(r({},t),e)),n},u=function(e){var t=c(e.components);return o.createElement(s.Provider,{value:t},e.children)},p={inlineCode:"code",wrapper:function(e){var t=e.children;return o.createElement(o.Fragment,{},t)}},d=o.forwardRef((function(e,t){var n=e.components,i=e.mdxType,a=e.originalType,s=e.parentName,u=l(e,["components","mdxType","originalType","parentName"]),d=c(n),m=i,f=d["".concat(s,".").concat(m)]||d[m]||p[m]||a;return n?o.createElement(f,r(r({ref:t},u),{},{components:n})):o.createElement(f,r({ref:t},u))}));function m(e,t){var n=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var a=n.length,r=new Array(a);r[0]=d;var l={};for(var s in t)hasOwnProperty.call(t,s)&&(l[s]=t[s]);l.originalType=e,l.mdxType="string"==typeof e?e:i,r[1]=l;for(var c=2;c{n.r(t),n.d(t,{assets:()=>s,contentTitle:()=>r,default:()=>p,frontMatter:()=>a,metadata:()=>l,toc:()=>c});var o=n(7462),i=(n(7294),n(3905));const a={slug:"code-of-conduct",title:"Code of Conduct",sidebar_label:"Code of Conduct"},r=void 0,l={unversionedId:"code-of-conduct",id:"code-of-conduct",title:"Code of Conduct",description:"Our Pledge",source:"@site/community/code-of-conduct.md",sourceDirName:".",slug:"/code-of-conduct",permalink:"/community/code-of-conduct",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/code-of-conduct.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"code-of-conduct",title:"Code of Conduct",sidebar_label:"Code of Conduct"},sidebar:"mainSidebar",previous:{title:"Values",permalink:"/community/community-values"},next:{title:"Expectations",permalink:"/community/expectations"}},s={},c=[{value:"Our Pledge",id:"our-pledge",level:2},{value:"Our Standards",id:"our-standards",level:2},{value:"Enforcement Responsibilities",id:"enforcement-responsibilities",level:2},{value:"Scope",id:"scope",level:2},{value:"Enforcement",id:"enforcement",level:2},{value:"Enforcement Guidelines",id:"enforcement-guidelines",level:2},{value:"1. Correction",id:"1-correction",level:3},{value:"2. Warning",id:"2-warning",level:3},{value:"3. Temporary Ban",id:"3-temporary-ban",level:3},{value:"4. Permanent Ban",id:"4-permanent-ban",level:3},{value:"Attribution",id:"attribution",level:2}],u={toc:c};function p(e){let{components:t,...n}=e;return(0,i.kt)("wrapper",(0,o.Z)({},u,n,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"our-pledge"},"Our Pledge"),(0,i.kt)("p",null,"We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation."),(0,i.kt)("p",null,"We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community."),(0,i.kt)("h2",{id:"our-standards"},"Our Standards"),(0,i.kt)("p",null,"Examples of behavior that contributes to a positive environment for our community include:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Demonstrating empathy and kindness toward other people"),(0,i.kt)("li",{parentName:"ul"},"Being respectful of differing opinions, viewpoints, and experiences"),(0,i.kt)("li",{parentName:"ul"},"Giving and gracefully accepting constructive feedback"),(0,i.kt)("li",{parentName:"ul"},"Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience"),(0,i.kt)("li",{parentName:"ul"},"Focusing on what is best not just for us as individuals, but for the overall community")),(0,i.kt)("p",null,"Examples of unacceptable behavior include:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"The use of sexualized language or imagery, and sexual attention or advances of any kind"),(0,i.kt)("li",{parentName:"ul"},"Trolling, insulting or derogatory comments, and personal or political attacks"),(0,i.kt)("li",{parentName:"ul"},"Public or private harassment"),(0,i.kt)("li",{parentName:"ul"},"Publishing others' private information, such as a physical or email address, without their explicit permission"),(0,i.kt)("li",{parentName:"ul"},"Other conduct which could reasonably be considered inappropriate in a professional setting")),(0,i.kt)("h2",{id:"enforcement-responsibilities"},"Enforcement Responsibilities"),(0,i.kt)("p",null,"Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful."),(0,i.kt)("p",null,"Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate."),(0,i.kt)("h2",{id:"scope"},"Scope"),(0,i.kt)("p",null,"This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event."),(0,i.kt)("h2",{id:"enforcement"},"Enforcement"),(0,i.kt)("p",null,"Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at ",(0,i.kt)("a",{parentName:"p",href:"mailto:community@redkubes.com."},"community@redkubes.com.")," All complaints will be reviewed and investigated promptly and fairly."),(0,i.kt)("p",null,"All community leaders are obligated to respect the privacy and security of the reporter of any incident."),(0,i.kt)("h2",{id:"enforcement-guidelines"},"Enforcement Guidelines"),(0,i.kt)("p",null,"Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:"),(0,i.kt)("h3",{id:"1-correction"},"1. Correction"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested."),(0,i.kt)("h3",{id:"2-warning"},"2. Warning"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": A violation through a single incident or series of actions."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban."),(0,i.kt)("h3",{id:"3-temporary-ban"},"3. Temporary Ban"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": A serious violation of community standards, including sustained inappropriate behavior."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban."),(0,i.kt)("h3",{id:"4-permanent-ban"},"4. Permanent Ban"),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Community Impact"),": Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals."),(0,i.kt)("p",null,(0,i.kt)("strong",{parentName:"p"},"Consequence"),": A permanent ban from any sort of public interaction within the community."),(0,i.kt)("h2",{id:"attribution"},"Attribution"),(0,i.kt)("p",null,"This Code of Conduct is adapted from the ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org"},"Contributor Covenant"),", version 2.0, available at ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org/version/2/0/code_of_conduct.html"},"v2.0"),"."),(0,i.kt)("p",null,"Community Impact Guidelines were inspired by ",(0,i.kt)("a",{parentName:"p",href:"https://github.com/mozilla/diversity"},"Mozilla's code of conduct enforcement ladder"),"."),(0,i.kt)("p",null,"For answers to common questions about this code of conduct, see the FAQ at ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org/faq"},"https://www.contributor-covenant.org/faq"),". Translations are available at ",(0,i.kt)("a",{parentName:"p",href:"https://www.contributor-covenant.org/translations"},"https://www.contributor-covenant.org/translations"),"."))}p.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/c642c7e8.2136c116.js b/assets/js/c642c7e8.142d5454.js similarity index 98% rename from assets/js/c642c7e8.2136c116.js rename to assets/js/c642c7e8.142d5454.js index 04293d45f..7870a6f4c 100644 --- a/assets/js/c642c7e8.2136c116.js +++ b/assets/js/c642c7e8.142d5454.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[512],{3905:(e,t,o)=>{o.d(t,{Zo:()=>c,kt:()=>p});var n=o(7294);function r(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function a(e){for(var t=1;t=0||(r[o]=e[o]);return r}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(r[o]=e[o])}return r}var u=n.createContext({}),s=function(e){var t=n.useContext(u),o=t;return e&&(o="function"==typeof e?e(t):a(a({},t),e)),o},c=function(e){var t=s(e.components);return n.createElement(u.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},m=n.forwardRef((function(e,t){var o=e.components,r=e.mdxType,i=e.originalType,u=e.parentName,c=l(e,["components","mdxType","originalType","parentName"]),m=s(o),p=r,f=m["".concat(u,".").concat(p)]||m[p]||d[p]||i;return o?n.createElement(f,a(a({ref:t},c),{},{components:o})):n.createElement(f,a({ref:t},c))}));function p(e,t){var o=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var i=o.length,a=new Array(i);a[0]=m;var l={};for(var u in t)hasOwnProperty.call(t,u)&&(l[u]=t[u]);l.originalType=e,l.mdxType="string"==typeof e?e:r,a[1]=l;for(var s=2;s{o.r(t),o.d(t,{assets:()=>u,contentTitle:()=>a,default:()=>d,frontMatter:()=>i,metadata:()=>l,toc:()=>s});var n=o(7462),r=(o(7294),o(3905));const i={title:"Welcome to our community",slug:"welcome",sidebar_label:"Welcome"},a=void 0,l={unversionedId:"welcome",id:"welcome",title:"Welcome to our community",description:"So you are interested to get involved with Otomi? Awesome! This guide will help you understand the overall organization of the project, and direct you to the best places to get started. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged. All feedback is welcome!",source:"@site/community/welcome.md",sourceDirName:".",slug:"/welcome",permalink:"/community/welcome",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/welcome.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{title:"Welcome to our community",slug:"welcome",sidebar_label:"Welcome"},sidebar:"mainSidebar",next:{title:"Values",permalink:"/community/community-values"}},u={},s=[{value:"Prerequisites",id:"prerequisites",level:2},{value:"Code of Conduct",id:"code-of-conduct",level:3},{value:"Developer guide",id:"developer-guide",level:3},{value:"Setting up your development environment",id:"setting-up-your-development-environment",level:3},{value:"Community Expectations and Roles",id:"community-expectations-and-roles",level:3}],c={toc:s};function d(e){let{components:t,...o}=e;return(0,r.kt)("wrapper",(0,n.Z)({},c,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"So you are interested to get involved with Otomi? Awesome! This guide will help you understand the overall organization of the project, and direct you to the best places to get started. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged. All feedback is welcome!"),(0,r.kt)("p",null,"This document is the single source of truth for how to contribute to the following code bases:"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://github.com/redkubes/otomi-core/"},"otomi-core"),": The heart of Otomi, a monorepo containing all the apps and configurations"),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://github.com/redkubes/otomi-tasks/"},"otomi-tasks"),": The tasks used by core to massage apps to adhere to the configurations"),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://github.com/redkubes/otomi-clients/"},"otomi-clients"),": The openapi generator for the clients used by the tasks")),(0,r.kt)("h2",{id:"prerequisites"},"Prerequisites"),(0,r.kt)("p",null,"Before submitting code to Otomi, you should first complete the following prerequisites. Completing these steps will make your first contribution easier:"),(0,r.kt)("h3",{id:"code-of-conduct"},"Code of Conduct"),(0,r.kt)("p",null,"Please make sure to read and observe the ",(0,r.kt)("a",{parentName:"p",href:"/community/code-of-conduct"},"Code of Conduct")," and\n",(0,r.kt)("a",{parentName:"p",href:"/community/community-values"},"Community Values")),(0,r.kt)("h3",{id:"developer-guide"},"Developer guide"),(0,r.kt)("p",null,"Effective development starts with an understanding the code structure and the relationship between different components of the system. Read the ",(0,r.kt)("a",{parentName:"p",href:"https://github.com/redkubes/otomi-core/blob/main/docs/development.md"},"Code development guide")," to learn how to develop on Otomi."),(0,r.kt)("h3",{id:"setting-up-your-development-environment"},"Setting up your development environment"),(0,r.kt)("p",null,"It is not required to set up a developer environment in order to contribute to Otomi, but if you do plan to contribute code changes, follow the instructions in the Developer Docs on how to ",(0,r.kt)("a",{parentName:"p",href:"https://github.com/redkubes/otomi-core/blob/main/docs/setup.md"},"Set up your development environment"),"."),(0,r.kt)("h3",{id:"community-expectations-and-roles"},"Community Expectations and Roles"),(0,r.kt)("p",null,"Otomi is a community project. Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment."),(0,r.kt)("p",null,"Please read and review the ",(0,r.kt)("a",{parentName:"p",href:"/community/expectations"},"Contribution Expectations")," for an understanding of code and review expectations."))}d.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[512],{3905:(e,t,o)=>{o.d(t,{Zo:()=>c,kt:()=>p});var n=o(7294);function r(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function a(e){for(var t=1;t=0||(r[o]=e[o]);return r}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(r[o]=e[o])}return r}var u=n.createContext({}),s=function(e){var t=n.useContext(u),o=t;return e&&(o="function"==typeof e?e(t):a(a({},t),e)),o},c=function(e){var t=s(e.components);return n.createElement(u.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},m=n.forwardRef((function(e,t){var o=e.components,r=e.mdxType,i=e.originalType,u=e.parentName,c=l(e,["components","mdxType","originalType","parentName"]),m=s(o),p=r,f=m["".concat(u,".").concat(p)]||m[p]||d[p]||i;return o?n.createElement(f,a(a({ref:t},c),{},{components:o})):n.createElement(f,a({ref:t},c))}));function p(e,t){var o=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var i=o.length,a=new Array(i);a[0]=m;var l={};for(var u in t)hasOwnProperty.call(t,u)&&(l[u]=t[u]);l.originalType=e,l.mdxType="string"==typeof e?e:r,a[1]=l;for(var s=2;s{o.r(t),o.d(t,{assets:()=>u,contentTitle:()=>a,default:()=>d,frontMatter:()=>i,metadata:()=>l,toc:()=>s});var n=o(7462),r=(o(7294),o(3905));const i={title:"Welcome to our community",slug:"welcome",sidebar_label:"Welcome"},a=void 0,l={unversionedId:"welcome",id:"welcome",title:"Welcome to our community",description:"So you are interested to get involved with Otomi? Awesome! This guide will help you understand the overall organization of the project, and direct you to the best places to get started. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged. All feedback is welcome!",source:"@site/community/welcome.md",sourceDirName:".",slug:"/welcome",permalink:"/community/welcome",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/welcome.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{title:"Welcome to our community",slug:"welcome",sidebar_label:"Welcome"},sidebar:"mainSidebar",next:{title:"Values",permalink:"/community/community-values"}},u={},s=[{value:"Prerequisites",id:"prerequisites",level:2},{value:"Code of Conduct",id:"code-of-conduct",level:3},{value:"Developer guide",id:"developer-guide",level:3},{value:"Setting up your development environment",id:"setting-up-your-development-environment",level:3},{value:"Community Expectations and Roles",id:"community-expectations-and-roles",level:3}],c={toc:s};function d(e){let{components:t,...o}=e;return(0,r.kt)("wrapper",(0,n.Z)({},c,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("p",null,"So you are interested to get involved with Otomi? Awesome! This guide will help you understand the overall organization of the project, and direct you to the best places to get started. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged. All feedback is welcome!"),(0,r.kt)("p",null,"This document is the single source of truth for how to contribute to the following code bases:"),(0,r.kt)("ul",null,(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://github.com/redkubes/otomi-core/"},"otomi-core"),": The heart of Otomi, a monorepo containing all the apps and configurations"),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://github.com/redkubes/otomi-tasks/"},"otomi-tasks"),": The tasks used by core to massage apps to adhere to the configurations"),(0,r.kt)("li",{parentName:"ul"},(0,r.kt)("a",{parentName:"li",href:"https://github.com/redkubes/otomi-clients/"},"otomi-clients"),": The openapi generator for the clients used by the tasks")),(0,r.kt)("h2",{id:"prerequisites"},"Prerequisites"),(0,r.kt)("p",null,"Before submitting code to Otomi, you should first complete the following prerequisites. Completing these steps will make your first contribution easier:"),(0,r.kt)("h3",{id:"code-of-conduct"},"Code of Conduct"),(0,r.kt)("p",null,"Please make sure to read and observe the ",(0,r.kt)("a",{parentName:"p",href:"/community/code-of-conduct"},"Code of Conduct")," and\n",(0,r.kt)("a",{parentName:"p",href:"/community/community-values"},"Community Values")),(0,r.kt)("h3",{id:"developer-guide"},"Developer guide"),(0,r.kt)("p",null,"Effective development starts with an understanding the code structure and the relationship between different components of the system. Read the ",(0,r.kt)("a",{parentName:"p",href:"https://github.com/redkubes/otomi-core/blob/main/docs/development.md"},"Code development guide")," to learn how to develop on Otomi."),(0,r.kt)("h3",{id:"setting-up-your-development-environment"},"Setting up your development environment"),(0,r.kt)("p",null,"It is not required to set up a developer environment in order to contribute to Otomi, but if you do plan to contribute code changes, follow the instructions in the Developer Docs on how to ",(0,r.kt)("a",{parentName:"p",href:"https://github.com/redkubes/otomi-core/blob/main/docs/setup.md"},"Set up your development environment"),"."),(0,r.kt)("h3",{id:"community-expectations-and-roles"},"Community Expectations and Roles"),(0,r.kt)("p",null,"Otomi is a community project. Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment."),(0,r.kt)("p",null,"Please read and review the ",(0,r.kt)("a",{parentName:"p",href:"/community/expectations"},"Contribution Expectations")," for an understanding of code and review expectations."))}d.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/d673e682.87a4a0f3.js b/assets/js/d673e682.47198934.js similarity index 98% rename from assets/js/d673e682.87a4a0f3.js rename to assets/js/d673e682.47198934.js index c5051e1dd..72f191938 100644 --- a/assets/js/d673e682.87a4a0f3.js +++ b/assets/js/d673e682.47198934.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[3120],{3905:(e,t,r)=>{r.d(t,{Zo:()=>u,kt:()=>m});var o=r(7294);function n(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function a(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);t&&(o=o.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,o)}return r}function i(e){for(var t=1;t=0||(n[r]=e[r]);return n}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(n[r]=e[r])}return n}var c=o.createContext({}),l=function(e){var t=o.useContext(c),r=t;return e&&(r="function"==typeof e?e(t):i(i({},t),e)),r},u=function(e){var t=l(e.components);return o.createElement(c.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return o.createElement(o.Fragment,{},t)}},p=o.forwardRef((function(e,t){var r=e.components,n=e.mdxType,a=e.originalType,c=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),p=l(r),m=n,h=p["".concat(c,".").concat(m)]||p[m]||d[m]||a;return r?o.createElement(h,i(i({ref:t},u),{},{components:r})):o.createElement(h,i({ref:t},u))}));function m(e,t){var r=arguments,n=t&&t.mdxType;if("string"==typeof e||n){var a=r.length,i=new Array(a);i[0]=p;var s={};for(var c in t)hasOwnProperty.call(t,c)&&(s[c]=t[c]);s.originalType=e,s.mdxType="string"==typeof e?e:n,i[1]=s;for(var l=2;l{r.r(t),r.d(t,{assets:()=>c,contentTitle:()=>i,default:()=>d,frontMatter:()=>a,metadata:()=>s,toc:()=>l});var o=r(7462),n=(r(7294),r(3905));const a={slug:"ci-cd",title:"CI/CD",sidebar_label:"CI/CD"},i=void 0,s={unversionedId:"use-cases/ci-cd",id:"use-cases/ci-cd",title:"CI/CD",description:"Introduction",source:"@site/product/use-cases/ci-cd.md",sourceDirName:"use-cases",slug:"/use-cases/ci-cd",permalink:"/product/use-cases/ci-cd",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/ci-cd.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"ci-cd",title:"CI/CD",sidebar_label:"CI/CD"},sidebar:"mainSidebar",previous:{title:"Multi-tenancy",permalink:"/product/use-cases/multi-tenancy"},next:{title:"Serverless",permalink:"/product/use-cases/serverless"}},c={},l=[{value:"Introduction",id:"introduction",level:2},{value:"CI with Otomi",id:"ci-with-otomi",level:2},{value:"CD with Otomi",id:"cd-with-otomi",level:2}],u={toc:l};function d(e){let{components:t,...r}=e;return(0,n.kt)("wrapper",(0,o.Z)({},u,r,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h2",{id:"introduction"},"Introduction"),(0,n.kt)("p",null,"Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. The integrated tools mainly focus on Continuous Deployment (to automatically deploy code changes after the build stage) and on all runtime controls. When using Otomi, we advice to setup a seprate CI environment (using specialized CI tools like GitHub Actions or CircleCI) where artifacts (images) are build and then pushed to an image registry (like Harbor provided by Otomi). But with integrated tools like Gitea and Tekton, Otomi can in some cases also be used for Continuous Integration (CI). This can be especially interesting in greenfield environments (where there is (not yet) a full CI toolset implemented) or in isolated environments (where developers don't have access to cloud CI services)."),(0,n.kt)("h2",{id:"ci-with-otomi"},"CI with Otomi"),(0,n.kt)("p",null,"Users on the platform can get access to an organization in Gitea. See ",(0,n.kt)("a",{parentName:"p",href:"https://docs.gitea.io/en-us/comparison/"},"here")," for a full list of all Gitea features and a comparison with other self-hosted Git solutions."),(0,n.kt)("p",null,"Otomi also includes Tekton pipelines. Tekton is used for the build feature in Otomi. The build feature can be used to build images from source using Kaniko (when there is a Docker file), or Buildpacks. To use the build feature, source code needs to be in a private Gitea repo, or in a public git repo. Other private repo's can also be replicated to Gitea."),(0,n.kt)("h2",{id:"cd-with-otomi"},"CD with Otomi"),(0,n.kt)("p",null,"The most common workflow when using Otomi starts when an artifact (image) has been build. Using the workloads feature in Otomi, images can be deployed using a Helm chart from the Developer Catalog."),(0,n.kt)("p",null,"Otomi uses the ",(0,n.kt)("inlineCode",{parentName:"p"},"otomi/charts")," repository in Gitea that contains a library of curated Helm charts that are offered as a quick start. The quick start Helm charts can be adjusted or replaced by your custom (Golden path) Helm charts."),(0,n.kt)("p",null,"When a workload specification (a combination of a Helm chart with custom values) has been created, Otomi automatically creates an Argo CD applicationset that deploys the configured chart. A workload can also be configured with the ",(0,n.kt)("a",{parentName:"p",href:"https://argocd-image-updater.readthedocs.io/en/stable/"},"Argo CD Image Updater")," that can check for new versions of images that are deployed with by the workload and then automatically update to the latest allowed version. The Argo CD Image Updater is only supported in combination with Otomi workloads and images stored in Harbor."))}d.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[3120],{3905:(e,t,r)=>{r.d(t,{Zo:()=>u,kt:()=>m});var o=r(7294);function n(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function a(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);t&&(o=o.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,o)}return r}function i(e){for(var t=1;t=0||(n[r]=e[r]);return n}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(o=0;o=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(n[r]=e[r])}return n}var c=o.createContext({}),l=function(e){var t=o.useContext(c),r=t;return e&&(r="function"==typeof e?e(t):i(i({},t),e)),r},u=function(e){var t=l(e.components);return o.createElement(c.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return o.createElement(o.Fragment,{},t)}},p=o.forwardRef((function(e,t){var r=e.components,n=e.mdxType,a=e.originalType,c=e.parentName,u=s(e,["components","mdxType","originalType","parentName"]),p=l(r),m=n,h=p["".concat(c,".").concat(m)]||p[m]||d[m]||a;return r?o.createElement(h,i(i({ref:t},u),{},{components:r})):o.createElement(h,i({ref:t},u))}));function m(e,t){var r=arguments,n=t&&t.mdxType;if("string"==typeof e||n){var a=r.length,i=new Array(a);i[0]=p;var s={};for(var c in t)hasOwnProperty.call(t,c)&&(s[c]=t[c]);s.originalType=e,s.mdxType="string"==typeof e?e:n,i[1]=s;for(var l=2;l{r.r(t),r.d(t,{assets:()=>c,contentTitle:()=>i,default:()=>d,frontMatter:()=>a,metadata:()=>s,toc:()=>l});var o=r(7462),n=(r(7294),r(3905));const a={slug:"ci-cd",title:"CI/CD",sidebar_label:"CI/CD"},i=void 0,s={unversionedId:"use-cases/ci-cd",id:"use-cases/ci-cd",title:"CI/CD",description:"Introduction",source:"@site/product/use-cases/ci-cd.md",sourceDirName:"use-cases",slug:"/use-cases/ci-cd",permalink:"/product/use-cases/ci-cd",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/use-cases/ci-cd.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"ci-cd",title:"CI/CD",sidebar_label:"CI/CD"},sidebar:"mainSidebar",previous:{title:"Multi-tenancy",permalink:"/product/use-cases/multi-tenancy"},next:{title:"Serverless",permalink:"/product/use-cases/serverless"}},c={},l=[{value:"Introduction",id:"introduction",level:2},{value:"CI with Otomi",id:"ci-with-otomi",level:2},{value:"CD with Otomi",id:"cd-with-otomi",level:2}],u={toc:l};function d(e){let{components:t,...r}=e;return(0,n.kt)("wrapper",(0,o.Z)({},u,r,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h2",{id:"introduction"},"Introduction"),(0,n.kt)("p",null,"Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. The integrated tools mainly focus on Continuous Deployment (to automatically deploy code changes after the build stage) and on all runtime controls. When using Otomi, we advice to setup a seprate CI environment (using specialized CI tools like GitHub Actions or CircleCI) where artifacts (images) are build and then pushed to an image registry (like Harbor provided by Otomi). But with integrated tools like Gitea and Tekton, Otomi can in some cases also be used for Continuous Integration (CI). This can be especially interesting in greenfield environments (where there is (not yet) a full CI toolset implemented) or in isolated environments (where developers don't have access to cloud CI services)."),(0,n.kt)("h2",{id:"ci-with-otomi"},"CI with Otomi"),(0,n.kt)("p",null,"Users on the platform can get access to an organization in Gitea. See ",(0,n.kt)("a",{parentName:"p",href:"https://docs.gitea.io/en-us/comparison/"},"here")," for a full list of all Gitea features and a comparison with other self-hosted Git solutions."),(0,n.kt)("p",null,"Otomi also includes Tekton pipelines. Tekton is used for the build feature in Otomi. The build feature can be used to build images from source using Kaniko (when there is a Docker file), or Buildpacks. To use the build feature, source code needs to be in a private Gitea repo, or in a public git repo. Other private repo's can also be replicated to Gitea."),(0,n.kt)("h2",{id:"cd-with-otomi"},"CD with Otomi"),(0,n.kt)("p",null,"The most common workflow when using Otomi starts when an artifact (image) has been build. Using the workloads feature in Otomi, images can be deployed using a Helm chart from the Developer Catalog."),(0,n.kt)("p",null,"Otomi uses the ",(0,n.kt)("inlineCode",{parentName:"p"},"otomi/charts")," repository in Gitea that contains a library of curated Helm charts that are offered as a quick start. The quick start Helm charts can be adjusted or replaced by your custom (Golden path) Helm charts."),(0,n.kt)("p",null,"When a workload specification (a combination of a Helm chart with custom values) has been created, Otomi automatically creates an Argo CD applicationset that deploys the configured chart. A workload can also be configured with the ",(0,n.kt)("a",{parentName:"p",href:"https://argocd-image-updater.readthedocs.io/en/stable/"},"Argo CD Image Updater")," that can check for new versions of images that are deployed with by the workload and then automatically update to the latest allowed version. The Argo CD Image Updater is only supported in combination with Otomi workloads and images stored in Harbor."))}d.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/e878c199.d13050b3.js b/assets/js/e878c199.93aca584.js similarity index 99% rename from assets/js/e878c199.d13050b3.js rename to assets/js/e878c199.93aca584.js index 876928117..9e77a00f3 100644 --- a/assets/js/e878c199.d13050b3.js +++ b/assets/js/e878c199.93aca584.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2163],{3905:(e,t,o)=>{o.d(t,{Zo:()=>c,kt:()=>d});var n=o(7294);function r(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function a(e){for(var t=1;t=0||(r[o]=e[o]);return r}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(r[o]=e[o])}return r}var u=n.createContext({}),l=function(e){var t=n.useContext(u),o=t;return e&&(o="function"==typeof e?e(t):a(a({},t),e)),o},c=function(e){var t=l(e.components);return n.createElement(u.Provider,{value:t},e.children)},m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var o=e.components,r=e.mdxType,i=e.originalType,u=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),p=l(o),d=r,h=p["".concat(u,".").concat(d)]||p[d]||m[d]||i;return o?n.createElement(h,a(a({ref:t},c),{},{components:o})):n.createElement(h,a({ref:t},c))}));function d(e,t){var o=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var i=o.length,a=new Array(i);a[0]=p;var s={};for(var u in t)hasOwnProperty.call(t,u)&&(s[u]=t[u]);s.originalType=e,s.mdxType="string"==typeof e?e:r,a[1]=s;for(var l=2;l{o.r(t),o.d(t,{assets:()=>u,contentTitle:()=>a,default:()=>m,frontMatter:()=>i,metadata:()=>s,toc:()=>l});var n=o(7462),r=(o(7294),o(3905));const i={title:"Otomi Community Values",slug:"community-values",sidebar_label:"Values"},a="Otomi Community Values",s={unversionedId:"values",id:"values",title:"Otomi Community Values",description:'Otomi Community culture contributes substantially to the project\'s success. The following values (blatantly copied and adopted from kubernetes, as those are almost "universal") are central to this:',source:"@site/community/values.md",sourceDirName:".",slug:"/community-values",permalink:"/community/community-values",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/values.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{title:"Otomi Community Values",slug:"community-values",sidebar_label:"Values"},sidebar:"mainSidebar",previous:{title:"Welcome",permalink:"/community/welcome"},next:{title:"Code of Conduct",permalink:"/community/code-of-conduct"}},u={},l=[{value:"Distribution is better than centralization",id:"distribution-is-better-than-centralization",level:2},{value:"Community over product or company",id:"community-over-product-or-company",level:2},{value:"Automation over process",id:"automation-over-process",level:2},{value:"Inclusive is better than exclusive",id:"inclusive-is-better-than-exclusive",level:2},{value:"Evolution is better than stagnation",id:"evolution-is-better-than-stagnation",level:2}],c={toc:l};function m(e){let{components:t,...o}=e;return(0,r.kt)("wrapper",(0,n.Z)({},c,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("h1",{id:"otomi-community-values"},"Otomi Community Values"),(0,r.kt)("p",null,'Otomi Community culture contributes substantially to the project\'s success. The following values (blatantly copied and adopted from kubernetes, as those are almost "universal") are central to this:'),(0,r.kt)("h2",{id:"distribution-is-better-than-centralization"},"Distribution is better than centralization"),(0,r.kt)("p",null,"The scale of the Otomi project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation. Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstones of our community."),(0,r.kt)("h2",{id:"community-over-product-or-company"},"Community over product or company"),(0,r.kt)("p",null,"We are here as a community first. Our allegiance is to the intentional stewardship of the Otomi project for the benefit of all its members and users everywhere. We support working together publicly for the common goal of a vibrant interoperable ecosystem, providing an excellent experience for our users. Individuals gain status through work. Companies gain status through their commitments to support this community and fund the resources necessary for the project to operate."),(0,r.kt)("h2",{id:"automation-over-process"},"Automation over process"),(0,r.kt)("p",null,"Large projects have a lot of hard yet less exciting work. We value time spent automating repetitive work more highly than toil. Where work cannot be automated, our culture recognizes and rewards all types of contributions while recognizing that heroism is not sustainable."),(0,r.kt)("h2",{id:"inclusive-is-better-than-exclusive"},"Inclusive is better than exclusive"),(0,r.kt)("p",null,"Broadly successful and useful technologies require different perspectives and skill sets, which can only be heard in a welcoming and respectful environment. Community membership is a privilege, not a right. Community members earn leadership through effort, scope, quality, quantity, and duration of contributions. Our community respects the time and effort put into a discussion, regardless of where a contributor is on their growth path."),(0,r.kt)("h2",{id:"evolution-is-better-than-stagnation"},"Evolution is better than stagnation"),(0,r.kt)("p",null,"Openness to new ideas and studied technological evolution make Otomi a stronger project. Continual improvement, servant leadership, mentorship, and respect are the foundations of Otomi culture. Otomi community leaders have a duty to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up."),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},'"Culture eats strategy for breakfast." --Peter Drucker')))}m.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[2163],{3905:(e,t,o)=>{o.d(t,{Zo:()=>c,kt:()=>d});var n=o(7294);function r(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function i(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function a(e){for(var t=1;t=0||(r[o]=e[o]);return r}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(r[o]=e[o])}return r}var u=n.createContext({}),l=function(e){var t=n.useContext(u),o=t;return e&&(o="function"==typeof e?e(t):a(a({},t),e)),o},c=function(e){var t=l(e.components);return n.createElement(u.Provider,{value:t},e.children)},m={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},p=n.forwardRef((function(e,t){var o=e.components,r=e.mdxType,i=e.originalType,u=e.parentName,c=s(e,["components","mdxType","originalType","parentName"]),p=l(o),d=r,h=p["".concat(u,".").concat(d)]||p[d]||m[d]||i;return o?n.createElement(h,a(a({ref:t},c),{},{components:o})):n.createElement(h,a({ref:t},c))}));function d(e,t){var o=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var i=o.length,a=new Array(i);a[0]=p;var s={};for(var u in t)hasOwnProperty.call(t,u)&&(s[u]=t[u]);s.originalType=e,s.mdxType="string"==typeof e?e:r,a[1]=s;for(var l=2;l{o.r(t),o.d(t,{assets:()=>u,contentTitle:()=>a,default:()=>m,frontMatter:()=>i,metadata:()=>s,toc:()=>l});var n=o(7462),r=(o(7294),o(3905));const i={title:"Otomi Community Values",slug:"community-values",sidebar_label:"Values"},a="Otomi Community Values",s={unversionedId:"values",id:"values",title:"Otomi Community Values",description:'Otomi Community culture contributes substantially to the project\'s success. The following values (blatantly copied and adopted from kubernetes, as those are almost "universal") are central to this:',source:"@site/community/values.md",sourceDirName:".",slug:"/community-values",permalink:"/community/community-values",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/community/values.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{title:"Otomi Community Values",slug:"community-values",sidebar_label:"Values"},sidebar:"mainSidebar",previous:{title:"Welcome",permalink:"/community/welcome"},next:{title:"Code of Conduct",permalink:"/community/code-of-conduct"}},u={},l=[{value:"Distribution is better than centralization",id:"distribution-is-better-than-centralization",level:2},{value:"Community over product or company",id:"community-over-product-or-company",level:2},{value:"Automation over process",id:"automation-over-process",level:2},{value:"Inclusive is better than exclusive",id:"inclusive-is-better-than-exclusive",level:2},{value:"Evolution is better than stagnation",id:"evolution-is-better-than-stagnation",level:2}],c={toc:l};function m(e){let{components:t,...o}=e;return(0,r.kt)("wrapper",(0,n.Z)({},c,o,{components:t,mdxType:"MDXLayout"}),(0,r.kt)("h1",{id:"otomi-community-values"},"Otomi Community Values"),(0,r.kt)("p",null,'Otomi Community culture contributes substantially to the project\'s success. The following values (blatantly copied and adopted from kubernetes, as those are almost "universal") are central to this:'),(0,r.kt)("h2",{id:"distribution-is-better-than-centralization"},"Distribution is better than centralization"),(0,r.kt)("p",null,"The scale of the Otomi project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation. Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstones of our community."),(0,r.kt)("h2",{id:"community-over-product-or-company"},"Community over product or company"),(0,r.kt)("p",null,"We are here as a community first. Our allegiance is to the intentional stewardship of the Otomi project for the benefit of all its members and users everywhere. We support working together publicly for the common goal of a vibrant interoperable ecosystem, providing an excellent experience for our users. Individuals gain status through work. Companies gain status through their commitments to support this community and fund the resources necessary for the project to operate."),(0,r.kt)("h2",{id:"automation-over-process"},"Automation over process"),(0,r.kt)("p",null,"Large projects have a lot of hard yet less exciting work. We value time spent automating repetitive work more highly than toil. Where work cannot be automated, our culture recognizes and rewards all types of contributions while recognizing that heroism is not sustainable."),(0,r.kt)("h2",{id:"inclusive-is-better-than-exclusive"},"Inclusive is better than exclusive"),(0,r.kt)("p",null,"Broadly successful and useful technologies require different perspectives and skill sets, which can only be heard in a welcoming and respectful environment. Community membership is a privilege, not a right. Community members earn leadership through effort, scope, quality, quantity, and duration of contributions. Our community respects the time and effort put into a discussion, regardless of where a contributor is on their growth path."),(0,r.kt)("h2",{id:"evolution-is-better-than-stagnation"},"Evolution is better than stagnation"),(0,r.kt)("p",null,"Openness to new ideas and studied technological evolution make Otomi a stronger project. Continual improvement, servant leadership, mentorship, and respect are the foundations of Otomi culture. Otomi community leaders have a duty to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up."),(0,r.kt)("p",null,(0,r.kt)("strong",{parentName:"p"},'"Culture eats strategy for breakfast." --Peter Drucker')))}m.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/efe7c983.9241def9.js b/assets/js/efe7c983.20929ee8.js similarity index 99% rename from assets/js/efe7c983.9241def9.js rename to assets/js/efe7c983.20929ee8.js index ee1d4225b..10d5c8e92 100644 --- a/assets/js/efe7c983.9241def9.js +++ b/assets/js/efe7c983.20929ee8.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[9613],{3905:(e,t,r)=>{r.d(t,{Zo:()=>s,kt:()=>c});var a=r(7294);function n(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function o(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);t&&(a=a.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,a)}return r}function i(e){for(var t=1;t=0||(n[r]=e[r]);return n}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(a=0;a=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(n[r]=e[r])}return n}var p=a.createContext({}),u=function(e){var t=a.useContext(p),r=t;return e&&(r="function"==typeof e?e(t):i(i({},t),e)),r},s=function(e){var t=u(e.components);return a.createElement(p.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return a.createElement(a.Fragment,{},t)}},m=a.forwardRef((function(e,t){var r=e.components,n=e.mdxType,o=e.originalType,p=e.parentName,s=l(e,["components","mdxType","originalType","parentName"]),m=u(r),c=n,f=m["".concat(p,".").concat(c)]||m[c]||d[c]||o;return r?a.createElement(f,i(i({ref:t},s),{},{components:r})):a.createElement(f,i({ref:t},s))}));function c(e,t){var r=arguments,n=t&&t.mdxType;if("string"==typeof e||n){var o=r.length,i=new Array(o);i[0]=m;var l={};for(var p in t)hasOwnProperty.call(t,p)&&(l[p]=t[p]);l.originalType=e,l.mdxType="string"==typeof e?e:n,i[1]=l;for(var u=2;u{r.r(t),r.d(t,{assets:()=>p,contentTitle:()=>i,default:()=>d,frontMatter:()=>o,metadata:()=>l,toc:()=>u});var a=r(7462),n=(r(7294),r(3905));const o={slug:"roadmap",title:"Product Roadmap",sidebar_label:"Roadmap"},i="Roadmap",l={unversionedId:"roadmap",id:"roadmap",title:"Product Roadmap",description:"Supported Kubernetes version",source:"@site/product/roadmap.md",sourceDirName:".",slug:"/roadmap",permalink:"/product/roadmap",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/roadmap.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"roadmap",title:"Product Roadmap",sidebar_label:"Roadmap"},sidebar:"mainSidebar",previous:{title:"Otomi Projects",permalink:"/product/architecture"},next:{title:"FAQ",permalink:"/product/faq"}},p={},u=[{value:"Supported Kubernetes version",id:"supported-kubernetes-version",level:2},{value:"2023 Q4",id:"2023-q4",level:2},{value:"2024 Q1",id:"2024-q1",level:2},{value:"2024 Q2",id:"2024-q2",level:2},{value:"After Q2 2024",id:"after-q2-2024",level:2}],s={toc:u};function d(e){let{components:t,...r}=e;return(0,n.kt)("wrapper",(0,a.Z)({},s,r,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h1",{id:"roadmap"},"Roadmap"),(0,n.kt)("h2",{id:"supported-kubernetes-version"},"Supported Kubernetes version"),(0,n.kt)("p",null,"We are dedicated to maintain support for three different Kubernetes versions within a specific major version of Otomi. Whenever we decide to discontinue support for a particular Kubernetes version, we increment the major version of Otomi."),(0,n.kt)("table",null,(0,n.kt)("thead",{parentName:"table"},(0,n.kt)("tr",{parentName:"thead"},(0,n.kt)("th",{parentName:"tr",align:null},"Otomi Version"),(0,n.kt)("th",{parentName:"tr",align:null},"Supported Kubernetes version"),(0,n.kt)("th",{parentName:"tr",align:null},"Expected release date"))),(0,n.kt)("tbody",{parentName:"table"},(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},"v1.0.0"),(0,n.kt)("td",{parentName:"tr",align:null},"1.25, 1.26, 1.27"),(0,n.kt)("td",{parentName:"tr",align:null},"2023-09-28")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},"v2.0.0"),(0,n.kt)("td",{parentName:"tr",align:null},"1.25, 1.26, 1.27"),(0,n.kt)("td",{parentName:"tr",align:null},"2023-11-28")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},"v3.0.0"),(0,n.kt)("td",{parentName:"tr",align:null},"1.26, 1.27, 1.28"),(0,n.kt)("td",{parentName:"tr",align:null},"2024-03-28")))),(0,n.kt)("h2",{id:"2023-q4"},"2023 Q4"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Provide a developer catalog in Gitea \u2705"),(0,n.kt)("li",{parentName:"ul"},"Migrate platform pipeline from Drone to Tekton \u2705"),(0,n.kt)("li",{parentName:"ul"},"Implement status indicators within Otomi Console to keep Team users informed about the status of various components, including Build processes, Workload management, and Service availability \u2705"),(0,n.kt)("li",{parentName:"ul"},"Add Team and Platform Dashboards to provide an overview of team resource status using Prometheus metrics \u2705"),(0,n.kt)("li",{parentName:"ul"},"Leverage Argo CD to deploy Otomi apps and Teams \u2705"),(0,n.kt)("li",{parentName:"ul"},"Quality assurance cluster for continuous Otomi hardening and performance testing \u2705"),(0,n.kt)("li",{parentName:"ul"},"Provide UI interface for adding Helm charts to developer catalog in Gitea \u2705")),(0,n.kt)("h2",{id:"2024-q1"},"2024 Q1"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Add the option to add charts from ",(0,n.kt)("a",{parentName:"li",href:"https://artifacthub.io"},"artifacthub")," to the Catalog \ud83d\udd04"),(0,n.kt)("li",{parentName:"ul"},"Implement a new secret management solution (as a replacement for Hashicorp Vault) \ud83d\udd04"),(0,n.kt)("li",{parentName:"ul"},"Harden the Istio service mesh configuration"),(0,n.kt)("li",{parentName:"ul"},"Implement Gitea with a database managed by the CloudNativePG operator")),(0,n.kt)("h2",{id:"2024-q2"},"2024 Q2"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Enhance network policies across the platform"),(0,n.kt)("li",{parentName:"ul"},"Establish separate Kubernetes namespaces for Team Applications"),(0,n.kt)("li",{parentName:"ul"},"Ensure Otomi's NSA and CISA compliance"),(0,n.kt)("li",{parentName:"ul"},"Enable user configurable storage classes"),(0,n.kt)("li",{parentName:"ul"},"Provide disaster recovery procedures for Otomi core applications, such as Gitea, Keycloak and Harbor")),(0,n.kt)("h2",{id:"after-q2-2024"},"After Q2 2024"),(0,n.kt)("p",null,"After Q2 2024 we have the following goals:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Make Otomi more plugable by enabling users to bring their own platform apps"),(0,n.kt)("li",{parentName:"ul"},"Migrate to ambient mesh using eBPF"),(0,n.kt)("li",{parentName:"ul"},"Remove platform app forms in favor of generated values that can be customized in an editor")))}d.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[9613],{3905:(e,t,r)=>{r.d(t,{Zo:()=>s,kt:()=>c});var a=r(7294);function n(e,t,r){return t in e?Object.defineProperty(e,t,{value:r,enumerable:!0,configurable:!0,writable:!0}):e[t]=r,e}function o(e,t){var r=Object.keys(e);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);t&&(a=a.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),r.push.apply(r,a)}return r}function i(e){for(var t=1;t=0||(n[r]=e[r]);return n}(e,t);if(Object.getOwnPropertySymbols){var o=Object.getOwnPropertySymbols(e);for(a=0;a=0||Object.prototype.propertyIsEnumerable.call(e,r)&&(n[r]=e[r])}return n}var p=a.createContext({}),u=function(e){var t=a.useContext(p),r=t;return e&&(r="function"==typeof e?e(t):i(i({},t),e)),r},s=function(e){var t=u(e.components);return a.createElement(p.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return a.createElement(a.Fragment,{},t)}},m=a.forwardRef((function(e,t){var r=e.components,n=e.mdxType,o=e.originalType,p=e.parentName,s=l(e,["components","mdxType","originalType","parentName"]),m=u(r),c=n,f=m["".concat(p,".").concat(c)]||m[c]||d[c]||o;return r?a.createElement(f,i(i({ref:t},s),{},{components:r})):a.createElement(f,i({ref:t},s))}));function c(e,t){var r=arguments,n=t&&t.mdxType;if("string"==typeof e||n){var o=r.length,i=new Array(o);i[0]=m;var l={};for(var p in t)hasOwnProperty.call(t,p)&&(l[p]=t[p]);l.originalType=e,l.mdxType="string"==typeof e?e:n,i[1]=l;for(var u=2;u{r.r(t),r.d(t,{assets:()=>p,contentTitle:()=>i,default:()=>d,frontMatter:()=>o,metadata:()=>l,toc:()=>u});var a=r(7462),n=(r(7294),r(3905));const o={slug:"roadmap",title:"Product Roadmap",sidebar_label:"Roadmap"},i="Roadmap",l={unversionedId:"roadmap",id:"roadmap",title:"Product Roadmap",description:"Supported Kubernetes version",source:"@site/product/roadmap.md",sourceDirName:".",slug:"/roadmap",permalink:"/product/roadmap",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/roadmap.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"roadmap",title:"Product Roadmap",sidebar_label:"Roadmap"},sidebar:"mainSidebar",previous:{title:"Otomi Projects",permalink:"/product/architecture"},next:{title:"FAQ",permalink:"/product/faq"}},p={},u=[{value:"Supported Kubernetes version",id:"supported-kubernetes-version",level:2},{value:"2023 Q4",id:"2023-q4",level:2},{value:"2024 Q1",id:"2024-q1",level:2},{value:"2024 Q2",id:"2024-q2",level:2},{value:"After Q2 2024",id:"after-q2-2024",level:2}],s={toc:u};function d(e){let{components:t,...r}=e;return(0,n.kt)("wrapper",(0,a.Z)({},s,r,{components:t,mdxType:"MDXLayout"}),(0,n.kt)("h1",{id:"roadmap"},"Roadmap"),(0,n.kt)("h2",{id:"supported-kubernetes-version"},"Supported Kubernetes version"),(0,n.kt)("p",null,"We are dedicated to maintain support for three different Kubernetes versions within a specific major version of Otomi. Whenever we decide to discontinue support for a particular Kubernetes version, we increment the major version of Otomi."),(0,n.kt)("table",null,(0,n.kt)("thead",{parentName:"table"},(0,n.kt)("tr",{parentName:"thead"},(0,n.kt)("th",{parentName:"tr",align:null},"Otomi Version"),(0,n.kt)("th",{parentName:"tr",align:null},"Supported Kubernetes version"),(0,n.kt)("th",{parentName:"tr",align:null},"Expected release date"))),(0,n.kt)("tbody",{parentName:"table"},(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},"v1.0.0"),(0,n.kt)("td",{parentName:"tr",align:null},"1.25, 1.26, 1.27"),(0,n.kt)("td",{parentName:"tr",align:null},"2023-09-28")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},"v2.0.0"),(0,n.kt)("td",{parentName:"tr",align:null},"1.25, 1.26, 1.27"),(0,n.kt)("td",{parentName:"tr",align:null},"2023-11-28")),(0,n.kt)("tr",{parentName:"tbody"},(0,n.kt)("td",{parentName:"tr",align:null},"v3.0.0"),(0,n.kt)("td",{parentName:"tr",align:null},"1.26, 1.27, 1.28"),(0,n.kt)("td",{parentName:"tr",align:null},"2024-03-28")))),(0,n.kt)("h2",{id:"2023-q4"},"2023 Q4"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Provide a developer catalog in Gitea \u2705"),(0,n.kt)("li",{parentName:"ul"},"Migrate platform pipeline from Drone to Tekton \u2705"),(0,n.kt)("li",{parentName:"ul"},"Implement status indicators within Otomi Console to keep Team users informed about the status of various components, including Build processes, Workload management, and Service availability \u2705"),(0,n.kt)("li",{parentName:"ul"},"Add Team and Platform Dashboards to provide an overview of team resource status using Prometheus metrics \u2705"),(0,n.kt)("li",{parentName:"ul"},"Leverage Argo CD to deploy Otomi apps and Teams \u2705"),(0,n.kt)("li",{parentName:"ul"},"Quality assurance cluster for continuous Otomi hardening and performance testing \u2705"),(0,n.kt)("li",{parentName:"ul"},"Provide UI interface for adding Helm charts to developer catalog in Gitea \u2705")),(0,n.kt)("h2",{id:"2024-q1"},"2024 Q1"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Add the option to add charts from ",(0,n.kt)("a",{parentName:"li",href:"https://artifacthub.io"},"artifacthub")," to the Catalog \ud83d\udd04"),(0,n.kt)("li",{parentName:"ul"},"Implement a new secret management solution (as a replacement for Hashicorp Vault) \ud83d\udd04"),(0,n.kt)("li",{parentName:"ul"},"Harden the Istio service mesh configuration"),(0,n.kt)("li",{parentName:"ul"},"Implement Gitea with a database managed by the CloudNativePG operator")),(0,n.kt)("h2",{id:"2024-q2"},"2024 Q2"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Enhance network policies across the platform"),(0,n.kt)("li",{parentName:"ul"},"Establish separate Kubernetes namespaces for Team Applications"),(0,n.kt)("li",{parentName:"ul"},"Ensure Otomi's NSA and CISA compliance"),(0,n.kt)("li",{parentName:"ul"},"Enable user configurable storage classes"),(0,n.kt)("li",{parentName:"ul"},"Provide disaster recovery procedures for Otomi core applications, such as Gitea, Keycloak and Harbor")),(0,n.kt)("h2",{id:"after-q2-2024"},"After Q2 2024"),(0,n.kt)("p",null,"After Q2 2024 we have the following goals:"),(0,n.kt)("ul",null,(0,n.kt)("li",{parentName:"ul"},"Make Otomi more plugable by enabling users to bring their own platform apps"),(0,n.kt)("li",{parentName:"ul"},"Migrate to ambient mesh using eBPF"),(0,n.kt)("li",{parentName:"ul"},"Remove platform app forms in favor of generated values that can be customized in an editor")))}d.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/f1abdd8c.ed966a4c.js b/assets/js/f1abdd8c.5cf402fb.js similarity index 99% rename from assets/js/f1abdd8c.ed966a4c.js rename to assets/js/f1abdd8c.5cf402fb.js index 7c5c27702..6d59be81d 100644 --- a/assets/js/f1abdd8c.ed966a4c.js +++ b/assets/js/f1abdd8c.5cf402fb.js @@ -1 +1 @@ -"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[4734],{3905:(e,t,o)=>{o.d(t,{Zo:()=>p,kt:()=>m});var n=o(7294);function i(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function a(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function r(e){for(var t=1;t=0||(i[o]=e[o]);return i}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(i[o]=e[o])}return i}var s=n.createContext({}),u=function(e){var t=n.useContext(s),o=t;return e&&(o="function"==typeof e?e(t):r(r({},t),e)),o},p=function(e){var t=u(e.components);return n.createElement(s.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},c=n.forwardRef((function(e,t){var o=e.components,i=e.mdxType,a=e.originalType,s=e.parentName,p=l(e,["components","mdxType","originalType","parentName"]),c=u(o),m=i,h=c["".concat(s,".").concat(m)]||c[m]||d[m]||a;return o?n.createElement(h,r(r({ref:t},p),{},{components:o})):n.createElement(h,r({ref:t},p))}));function m(e,t){var o=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var a=o.length,r=new Array(a);r[0]=c;var l={};for(var s in t)hasOwnProperty.call(t,s)&&(l[s]=t[s]);l.originalType=e,l.mdxType="string"==typeof e?e:i,r[1]=l;for(var u=2;u{o.r(t),o.d(t,{assets:()=>s,contentTitle:()=>r,default:()=>d,frontMatter:()=>a,metadata:()=>l,toc:()=>u});var n=o(7462),i=(o(7294),o(3905));const a={slug:"faq",title:"FAQ"},r=void 0,l={unversionedId:"faq",id:"faq",title:"FAQ",description:"More about Otomi",source:"@site/product/faq.md",sourceDirName:".",slug:"/faq",permalink:"/product/faq",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/faq.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706082714,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"faq",title:"FAQ"},sidebar:"mainSidebar",previous:{title:"Roadmap",permalink:"/product/roadmap"},next:{title:"Overview",permalink:"/product/use-cases/overview"}},s={},u=[{value:"More about Otomi",id:"more-about-otomi",level:2},{value:"Setup and Installation",id:"setup-and-installation",level:2},{value:"Other",id:"other",level:2}],p={toc:u};function d(e){let{components:t,...o}=e;return(0,i.kt)("wrapper",(0,n.Z)({},p,o,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"more-about-otomi"},"More about Otomi"),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Is Otomi a lightweight version of Rancher or OpenShift"),(0,i.kt)("p",null,"No. Otomi is a pre-configured and curated package of open source projects combined with a self-service portal and requires an existing Kubernetes cluster to be installed on. Otomi can not be used to install a Kubernetes cluster.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Is Otomi some kind of Kubeapps"),(0,i.kt)("p",null,"We can imagine when looking at the list of all pre-configured and ready-to-use apps, you might get the impression that Otomi is some kind of application catalog for Kubernetes. But the opposite is true. When you install Otomi, you will get all of these apps and they\u2019re already configured for you, and they will work out-of-the-box. You can then use the web UI or values repository to adjust the configuration of these apps based on your own requirements."),(0,i.kt)("p",null,"Otomi itself comes with a Developer Catalog that can be customized do offer custom Helm charts (Golden path Templates) to developers to use.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Do I need to use Gitea for my code repositories?"),(0,i.kt)("p",null,"No. Otomi itself uses Gitea for 2 repositories: the ",(0,i.kt)("inlineCode",{parentName:"p"},"otomi/values")," and the ",(0,i.kt)("inlineCode",{parentName:"p"},"otomi/charts")," repositories. ",(0,i.kt)("inlineCode",{parentName:"p"},"otomi/values"),' is used for the "local bookkeeping" of the platform configuration and ',(0,i.kt)("inlineCode",{parentName:"p"},"otomi/charts")," is used for the Developer Catalog. Using external Git services for these repositories is not supported."),(0,i.kt)("p",null,"But it is not required to use Gitea for your own code repositories. Yes, Gitea can be used as a Git service for your own code projects, but if you are already using a Git service like Gitlab or GitHub, you are not forced to migrate."),(0,i.kt)("p",null,"The Build feature in Otomi is configured with credentials for Gitea private repositories, but it is also possible to use public Git repositories, or create a secret for an external Git service and use this secret.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"I already have a CI build pipeline. Do I need to use the Build feature in Otomi? "),(0,i.kt)("p",null,"No. If you already have a CI build pipeline you can keep using it. You can choose to push your images to Harbor in Otomi. For this you can download the Docker credentials in Otomi Console.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Do I need to use Harbor?"),(0,i.kt)("p",null,"No, using Harbor is optional. The advantage of using Harbor is that Otomi automatically adds a ",(0,i.kt)("inlineCode",{parentName:"p"},"pull-secret")," for Harbor to the Team namespace. If you would like to use an external image registry, then you will need to create the pull-secrets yourself.")),(0,i.kt)("h2",{id:"setup-and-installation"},"Setup and Installation"),(0,i.kt)("details",null,(0,i.kt)("summary",null,"What are the minimal requirements to install Otomi?"),(0,i.kt)("p",null,"Otomi requires a running Kubernetes cluster of version ",(0,i.kt)("inlineCode",{parentName:"p"},"1.25")," up to ",(0,i.kt)("inlineCode",{parentName:"p"},"1.27")," using a Node pool with at least ",(0,i.kt)("inlineCode",{parentName:"p"},"12 vCPU")," and ",(0,i.kt)("inlineCode",{parentName:"p"},"24 GiB memory"),", but more is recommended. When using the ",(0,i.kt)("inlineCode",{parentName:"p"},"custom")," provider (when installing Kubernetes on a unsupported provider), make sure Otomi can create a K8s LoadBalancer Service that is accessible from your machine (but not using 127.0.0.1).")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Where can I find all possible configuration options for Otomi?"),(0,i.kt)("p",null,"When installing Otomi with the helm chart you can find its ",(0,i.kt)("inlineCode",{parentName:"p"},"values-schema.json")," inside, which contains all the possible configuration parameters. It is generated from ",(0,i.kt)("a",{parentName:"p",href:"https://github.com/redkubes/otomi-core/blob/main/values-schema.yaml"},"otomi-core/values-schema.yaml"),".")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Can Otomi be deployed on an existing cluster?"),(0,i.kt)("p",null,"Yes, Otomi can be installed on an existing cluster as long as there are no namespaces that are also used by Otomi. We advise to install Otomi on a Vanilla Kubernetes cluster without any cloud specific add-ons installed.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Can I install Otomi without using a DNS zone?"),(0,i.kt)("p",null,"Yes, using a DNS zone for name resolution is optional (but prefferred). When installing Otomi with minimal values, nip.io is used for name resolution pointing to the public IP of the cloud load balancer.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"I don't have an external IdP like Azure AD. Can I still install Otomi?"),(0,i.kt)("p",null,"Yes, using an external IdP like Azure AD is optional. When installing Otomi without ",(0,i.kt)("inlineCode",{parentName:"p"},"OIDC")," values, Otomi will configure Keycloak as an IdP. You can create users in Keycloak and assign them to the pre-configured roles.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Can I install Otomi on my laptop using Minikube?"),(0,i.kt)("p",null,"Yes. You can use the Otomi ",(0,i.kt)("inlineCode",{parentName:"p"},"custom")," provider to install Otomi on Kubernetes running on your own hardware, including Minikube. Note that Otomi needs to be able to create a Kubernetes LoadBalancer service and the IP needs to be accessible for pods running in the cluster and for your local browser. ",(0,i.kt)("inlineCode",{parentName:"p"},"127.0.0.1")," can not be used, so running minikube with the Docker provider is not supported. Use the ",(0,i.kt)("a",{parentName:"p",href:"https://minikube.sigs.k8s.io/docs/drivers/hyperkit/"},"Hyperkit driver")," instead. Also note that Otomi does not support ARM."),(0,i.kt)("p",null,"Otomi is a complete platform suite and not a single purpose tool. This is why otomi requires a stable (cloud) infrastructure and sufficient resources. Running Otomi on your laptop is therefor not advised.")),(0,i.kt)("h2",{id:"other"},"Other"),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Do you provide commercial support?"),(0,i.kt)("p",null,"Yes, you can contact us for commercial support. ",(0,i.kt)("a",{parentName:"p",href:"https://redkubes.com"},"Red Kubes")," is the company behind Otomi.")))}d.isMDXComponent=!0}}]); \ No newline at end of file +"use strict";(self.webpackChunkredkubes_github_io=self.webpackChunkredkubes_github_io||[]).push([[4734],{3905:(e,t,o)=>{o.d(t,{Zo:()=>p,kt:()=>m});var n=o(7294);function i(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function a(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function r(e){for(var t=1;t=0||(i[o]=e[o]);return i}(e,t);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);for(n=0;n=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(i[o]=e[o])}return i}var s=n.createContext({}),u=function(e){var t=n.useContext(s),o=t;return e&&(o="function"==typeof e?e(t):r(r({},t),e)),o},p=function(e){var t=u(e.components);return n.createElement(s.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},c=n.forwardRef((function(e,t){var o=e.components,i=e.mdxType,a=e.originalType,s=e.parentName,p=l(e,["components","mdxType","originalType","parentName"]),c=u(o),m=i,h=c["".concat(s,".").concat(m)]||c[m]||d[m]||a;return o?n.createElement(h,r(r({ref:t},p),{},{components:o})):n.createElement(h,r({ref:t},p))}));function m(e,t){var o=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var a=o.length,r=new Array(a);r[0]=c;var l={};for(var s in t)hasOwnProperty.call(t,s)&&(l[s]=t[s]);l.originalType=e,l.mdxType="string"==typeof e?e:i,r[1]=l;for(var u=2;u{o.r(t),o.d(t,{assets:()=>s,contentTitle:()=>r,default:()=>d,frontMatter:()=>a,metadata:()=>l,toc:()=>u});var n=o(7462),i=(o(7294),o(3905));const a={slug:"faq",title:"FAQ"},r=void 0,l={unversionedId:"faq",id:"faq",title:"FAQ",description:"More about Otomi",source:"@site/product/faq.md",sourceDirName:".",slug:"/faq",permalink:"/product/faq",draft:!1,editUrl:"https://github.com/redkubes/redkubes.github.io/edit/main/product/faq.md",tags:[],version:"current",lastUpdatedBy:"Sander Rodenhuis",lastUpdatedAt:1706083401,formattedLastUpdatedAt:"Jan 24, 2024",frontMatter:{slug:"faq",title:"FAQ"},sidebar:"mainSidebar",previous:{title:"Roadmap",permalink:"/product/roadmap"},next:{title:"Overview",permalink:"/product/use-cases/overview"}},s={},u=[{value:"More about Otomi",id:"more-about-otomi",level:2},{value:"Setup and Installation",id:"setup-and-installation",level:2},{value:"Other",id:"other",level:2}],p={toc:u};function d(e){let{components:t,...o}=e;return(0,i.kt)("wrapper",(0,n.Z)({},p,o,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h2",{id:"more-about-otomi"},"More about Otomi"),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Is Otomi a lightweight version of Rancher or OpenShift"),(0,i.kt)("p",null,"No. Otomi is a pre-configured and curated package of open source projects combined with a self-service portal and requires an existing Kubernetes cluster to be installed on. Otomi can not be used to install a Kubernetes cluster.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Is Otomi some kind of Kubeapps"),(0,i.kt)("p",null,"We can imagine when looking at the list of all pre-configured and ready-to-use apps, you might get the impression that Otomi is some kind of application catalog for Kubernetes. But the opposite is true. When you install Otomi, you will get all of these apps and they\u2019re already configured for you, and they will work out-of-the-box. You can then use the web UI or values repository to adjust the configuration of these apps based on your own requirements."),(0,i.kt)("p",null,"Otomi itself comes with a Developer Catalog that can be customized do offer custom Helm charts (Golden path Templates) to developers to use.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Do I need to use Gitea for my code repositories?"),(0,i.kt)("p",null,"No. Otomi itself uses Gitea for 2 repositories: the ",(0,i.kt)("inlineCode",{parentName:"p"},"otomi/values")," and the ",(0,i.kt)("inlineCode",{parentName:"p"},"otomi/charts")," repositories. ",(0,i.kt)("inlineCode",{parentName:"p"},"otomi/values"),' is used for the "local bookkeeping" of the platform configuration and ',(0,i.kt)("inlineCode",{parentName:"p"},"otomi/charts")," is used for the Developer Catalog. Using external Git services for these repositories is not supported."),(0,i.kt)("p",null,"But it is not required to use Gitea for your own code repositories. Yes, Gitea can be used as a Git service for your own code projects, but if you are already using a Git service like Gitlab or GitHub, you are not forced to migrate."),(0,i.kt)("p",null,"The Build feature in Otomi is configured with credentials for Gitea private repositories, but it is also possible to use public Git repositories, or create a secret for an external Git service and use this secret.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"I already have a CI build pipeline. Do I need to use the Build feature in Otomi? "),(0,i.kt)("p",null,"No. If you already have a CI build pipeline you can keep using it. You can choose to push your images to Harbor in Otomi. For this you can download the Docker credentials in Otomi Console.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Do I need to use Harbor?"),(0,i.kt)("p",null,"No, using Harbor is optional. The advantage of using Harbor is that Otomi automatically adds a ",(0,i.kt)("inlineCode",{parentName:"p"},"pull-secret")," for Harbor to the Team namespace. If you would like to use an external image registry, then you will need to create the pull-secrets yourself.")),(0,i.kt)("h2",{id:"setup-and-installation"},"Setup and Installation"),(0,i.kt)("details",null,(0,i.kt)("summary",null,"What are the minimal requirements to install Otomi?"),(0,i.kt)("p",null,"Otomi requires a running Kubernetes cluster of version ",(0,i.kt)("inlineCode",{parentName:"p"},"1.25")," up to ",(0,i.kt)("inlineCode",{parentName:"p"},"1.27")," using a Node pool with at least ",(0,i.kt)("inlineCode",{parentName:"p"},"12 vCPU")," and ",(0,i.kt)("inlineCode",{parentName:"p"},"24 GiB memory"),", but more is recommended. When using the ",(0,i.kt)("inlineCode",{parentName:"p"},"custom")," provider (when installing Kubernetes on a unsupported provider), make sure Otomi can create a K8s LoadBalancer Service that is accessible from your machine (but not using 127.0.0.1).")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Where can I find all possible configuration options for Otomi?"),(0,i.kt)("p",null,"When installing Otomi with the helm chart you can find its ",(0,i.kt)("inlineCode",{parentName:"p"},"values-schema.json")," inside, which contains all the possible configuration parameters. It is generated from ",(0,i.kt)("a",{parentName:"p",href:"https://github.com/redkubes/otomi-core/blob/main/values-schema.yaml"},"otomi-core/values-schema.yaml"),".")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Can Otomi be deployed on an existing cluster?"),(0,i.kt)("p",null,"Yes, Otomi can be installed on an existing cluster as long as there are no namespaces that are also used by Otomi. We advise to install Otomi on a Vanilla Kubernetes cluster without any cloud specific add-ons installed.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Can I install Otomi without using a DNS zone?"),(0,i.kt)("p",null,"Yes, using a DNS zone for name resolution is optional (but prefferred). When installing Otomi with minimal values, nip.io is used for name resolution pointing to the public IP of the cloud load balancer.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"I don't have an external IdP like Azure AD. Can I still install Otomi?"),(0,i.kt)("p",null,"Yes, using an external IdP like Azure AD is optional. When installing Otomi without ",(0,i.kt)("inlineCode",{parentName:"p"},"OIDC")," values, Otomi will configure Keycloak as an IdP. You can create users in Keycloak and assign them to the pre-configured roles.")),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Can I install Otomi on my laptop using Minikube?"),(0,i.kt)("p",null,"Yes. You can use the Otomi ",(0,i.kt)("inlineCode",{parentName:"p"},"custom")," provider to install Otomi on Kubernetes running on your own hardware, including Minikube. Note that Otomi needs to be able to create a Kubernetes LoadBalancer service and the IP needs to be accessible for pods running in the cluster and for your local browser. ",(0,i.kt)("inlineCode",{parentName:"p"},"127.0.0.1")," can not be used, so running minikube with the Docker provider is not supported. Use the ",(0,i.kt)("a",{parentName:"p",href:"https://minikube.sigs.k8s.io/docs/drivers/hyperkit/"},"Hyperkit driver")," instead. Also note that Otomi does not support ARM."),(0,i.kt)("p",null,"Otomi is a complete platform suite and not a single purpose tool. This is why otomi requires a stable (cloud) infrastructure and sufficient resources. Running Otomi on your laptop is therefor not advised.")),(0,i.kt)("h2",{id:"other"},"Other"),(0,i.kt)("details",null,(0,i.kt)("summary",null,"Do you provide commercial support?"),(0,i.kt)("p",null,"Yes, you can contact us for commercial support. ",(0,i.kt)("a",{parentName:"p",href:"https://redkubes.com"},"Red Kubes")," is the company behind Otomi.")))}d.isMDXComponent=!0}}]); \ No newline at end of file diff --git a/assets/js/runtime~main.110a1fa6.js b/assets/js/runtime~main.f463275f.js similarity index 73% rename from assets/js/runtime~main.110a1fa6.js rename to assets/js/runtime~main.f463275f.js index f3d4b19f2..9a1b60ce0 100644 --- a/assets/js/runtime~main.110a1fa6.js +++ b/assets/js/runtime~main.f463275f.js @@ -1 +1 @@ -(()=>{"use strict";var e,d,a,c,f,b={},t={};function r(e){var d=t[e];if(void 0!==d)return d.exports;var a=t[e]={id:e,loaded:!1,exports:{}};return b[e].call(a.exports,a,a.exports,r),a.loaded=!0,a.exports}r.m=b,r.c=t,e=[],r.O=(d,a,c,f)=>{if(!a){var b=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](a[o])))?a.splice(o--,1):(t=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[a,c,f]},r.n=e=>{var d=e&&e.__esModule?()=>e.default:()=>e;return r.d(d,{a:d}),d},a=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,c){if(1&c&&(e=this(e)),8&c)return e;if("object"==typeof e&&e){if(4&c&&e.__esModule)return e;if(16&c&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var b={};d=d||[null,a({}),a([]),a(a)];for(var t=2&c&&e;"object"==typeof t&&!~d.indexOf(t);t=a(t))Object.getOwnPropertyNames(t).forEach((d=>b[d]=()=>e[d]));return b.default=()=>e,r.d(f,b),f},r.d=(e,d)=>{for(var a in d)r.o(d,a)&&!r.o(e,a)&&Object.defineProperty(e,a,{enumerable:!0,get:d[a]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((d,a)=>(r.f[a](e,d),d)),[])),r.u=e=>"assets/js/"+({12:"cce2f323",53:"935f2afb",65:"1e3926cf",190:"9f25d002",192:"2a1f96be",253:"3c6d57b1",344:"5db37859",411:"80cc8fc2",439:"db2fd2f7",443:"9824b3d7",512:"c642c7e8",528:"e4550136",534:"c5c74bfd",537:"c9644b78",597:"99018ea3",634:"0d519d5d",767:"df2434c5",781:"a0650468",860:"a0cf5b3c",912:"1d911987",965:"d53aaf7f",1056:"94da8644",1104:"35ac0aef",1113:"4380e181",1195:"1830c2e3",1241:"e2cc03cb",1254:"443e3a65",1369:"6abedfc3",1390:"96d3f3ac",1391:"9cb4274e",1409:"73148982",1506:"ac482592",1515:"f34c6cc5",1573:"a722ee7a",1576:"c3a9c637",1591:"09735fc0",1658:"c1cd9779",1713:"db4c0e54",1717:"2afdefd3",1730:"69fd0b9a",1854:"be94a9c8",1872:"c42226db",1882:"8213a342",1913:"c9ff9b08",1948:"03eadeb8",2018:"042c512d",2020:"7f5d7fca",2036:"54cc2d4c",2084:"930e985e",2098:"00210a32",2117:"3d235714",2122:"5a2e1e49",2144:"aa3203ff",2163:"e878c199",2237:"1f668492",2248:"7d5c16d7",2276:"9a44d6ca",2280:"5ce65c80",2370:"afd24866",2430:"188da18d",2515:"70b0dc77",2552:"81f8c379",2615:"d8a040d1",2668:"d9893b92",2687:"56d1269f",2704:"10959509",2722:"14bc3799",2780:"3c110fea",2851:"842ea3d4",2869:"b458a144",3056:"1807f63e",3120:"d673e682",3121:"3b8b7efd",3126:"17a7c5fe",3237:"1df93b7f",3272:"052260a8",3418:"3fd50427",3458:"3ca1c20f",3474:"ab3bc09d",3520:"b4b7b186",3544:"cd151fd5",3563:"21fbcd7c",3576:"13689ae4",3635:"1f918bbd",3644:"c0fcc3ac",3927:"dfc1ee8e",3942:"5f4e8093",4011:"feda9f98",4027:"e6cdbc01",4041:"2f26dbd7",4234:"1a23fb22",4258:"c61e7c1f",4321:"6d553b82",4473:"1d3542c3",4493:"4892c042",4505:"ace391e9",4559:"5c5eecab",4576:"612b9100",4655:"2a3fc902",4717:"d76c6a89",4722:"e7ee1f4e",4724:"cb0338eb",4729:"c3428a3f",4734:"f1abdd8c",4791:"a3cca685",4825:"3a0feb37",4875:"da6d770b",4882:"20c7dd93",4890:"beacde48",5018:"871ddaf7",5022:"2d9c895d",5033:"ca4242f5",5039:"a6ef47a7",5092:"a92bb299",5195:"3379d6c0",5229:"08d2d3ef",5290:"98242336",5459:"a5fb0fed",5586:"d1ff794b",5616:"942fe4d7",5720:"646a49d4",5730:"b68546d1",5775:"46a4fdf9",5824:"81e06d7e",5914:"f50c0130",5920:"b04270fa",5940:"385dd0a0",6096:"0c3fdeeb",6128:"83b70ecd",6299:"48f8b5b9",6306:"e65ca800",6547:"1691c9ac",6576:"bcbdbf75",6611:"a353273a",6779:"940ad428",6820:"d40b8d5d",6866:"a6a14297",6871:"861ce6bc",6888:"af9df136",6906:"39901f0d",6946:"8924d81d",7015:"4f01d7c7",7227:"7545be8c",7263:"66ebdfe3",7282:"1dcded0d",7365:"6b7c6343",7386:"28c78037",7444:"af8b4e82",7498:"a39a834c",7514:"3765f133",7616:"306a8c6c",7622:"5cecd17a",7674:"270f6692",7683:"08d8079e",7763:"acbd0412",7778:"734d54da",7878:"386e030b",7896:"9ed16ae1",7918:"17896441",7920:"1a4e3797",7927:"1f25a778",7973:"46be4bcd",7980:"81b812c0",7984:"a47e2810",8028:"c4d36760",8052:"17725d1c",8129:"30f4d83c",8185:"b0500dc6",8344:"1afc8419",8367:"03608398",8379:"3829398f",8383:"246b758f",8392:"0be2dc55",8442:"66c551f1",8479:"12174d43",8506:"9899ea6d",8587:"1fba201f",8589:"8f69df39",8607:"2df7e88d",8643:"b00e4863",8696:"541249eb",8801:"84b718dc",8852:"9b2db8ea",8897:"af477ebb",9109:"e216824f",9153:"ed3faf6d",9216:"5cb822a3",9237:"bde17074",9329:"db897548",9514:"1be78505",9613:"efe7c983",9620:"f80fe6b5",9637:"bb6d4937",9683:"7ea98ab3",9742:"c3394322",9753:"5c500e73",9892:"59a7de32"}[e]||e)+"."+{12:"2a33b6ac",53:"7cd2029a",65:"4cd8aa47",190:"779054a2",192:"b799d157",253:"22ed9be3",344:"9f73e243",411:"bdc002d8",439:"5a22fe77",443:"78eb0ad0",512:"2136c116",528:"dbf73ef3",534:"abbfdd1a",537:"7eda6524",597:"1f55f342",634:"0f1de44e",767:"73e04e50",781:"15cc1d5c",860:"f67d241f",912:"fc8668ed",965:"aa118d47",1056:"c33689e0",1104:"dc30eefe",1113:"022d06c3",1195:"2102d558",1241:"3e9007d4",1254:"ae9efd58",1369:"5c5f7b4d",1390:"9ff5acb5",1391:"36753501",1409:"041cb4ba",1506:"89629294",1515:"f6e4afae",1573:"7b212d02",1576:"0276b480",1591:"ac2dd1b6",1658:"f2b1173b",1713:"2f88480b",1717:"a47a00a9",1730:"c2dbc3f6",1854:"9af8a157",1872:"e5705790",1882:"e8bcbc38",1913:"4135aa12",1948:"ee751a12",2018:"6637f92d",2020:"044452d9",2036:"704e03a9",2084:"3acf6bf4",2098:"7cdc46ec",2117:"ed09bcde",2122:"9326cc9a",2144:"04779f9f",2163:"d13050b3",2237:"3e8a5736",2248:"0d29de02",2276:"16f6b590",2280:"e235d932",2370:"abdb5727",2430:"a38c79ab",2515:"fde1e8cb",2552:"a1c59d23",2615:"8a939763",2668:"ffdba4cf",2687:"e68c91f3",2704:"c06de943",2722:"54b527a9",2780:"baa7b06f",2851:"6d3690f6",2869:"70c0a9d2",3056:"0d30c808",3120:"87a4a0f3",3121:"65e3b56a",3126:"04bb0ba9",3237:"b5192427",3272:"91f7c0e9",3418:"7b5f22bf",3458:"ef476d6f",3474:"52a20100",3520:"4ab79471",3544:"26596b3b",3563:"2be8af33",3576:"5fa63b51",3635:"4e9c014c",3644:"8e6b8ffb",3927:"b788817a",3942:"f6fc3714",4011:"0470c9ef",4027:"260385ee",4041:"502b065a",4234:"2b7f2784",4258:"b2a0890b",4321:"06a915a2",4473:"cd42aa75",4493:"6b7c10eb",4505:"971270f4",4559:"8c3d8ec5",4576:"6ac986db",4655:"bc3dc600",4717:"8ffe54c0",4722:"40e3100f",4724:"d3573256",4729:"60038b89",4734:"ed966a4c",4791:"6b8840f5",4825:"04a4c13c",4875:"de851390",4882:"d115d64e",4890:"f490fbc0",4972:"6875cba6",5018:"1033b43d",5022:"b7386f49",5033:"5c525ac5",5039:"d77eef67",5092:"0185884b",5195:"a6354782",5229:"9e9b0fd4",5290:"af6ab2d9",5459:"eace920b",5586:"0d501801",5616:"99ce5d04",5720:"76bdbf5f",5730:"c975c302",5775:"64d64cb1",5824:"9c895585",5914:"1a54a059",5920:"798381e2",5940:"dc015827",6096:"613977f7",6128:"bf4ada5d",6299:"8cb8529e",6306:"17387992",6547:"7d7250fc",6576:"1a720df3",6611:"128223b0",6779:"c450c81c",6780:"c21aadea",6820:"896345ac",6866:"1734713d",6871:"db0cefc5",6888:"70a31f3d",6906:"d061228f",6945:"bfc572ea",6946:"226f60e1",7015:"83164f21",7227:"dca04c5e",7263:"aa0c7060",7282:"27541278",7365:"686912f0",7386:"1709a753",7444:"6587e11d",7498:"359b28f3",7514:"e59acb6d",7616:"8650c839",7622:"959856ea",7674:"6844eb90",7683:"a7c6d795",7763:"7876f34a",7778:"a6fb3afa",7878:"2f0e6b91",7896:"e2b5e295",7918:"c4c3429a",7920:"54851adb",7927:"23a53692",7973:"9b2e864d",7980:"bc1af9c9",7984:"d951b317",8028:"3e9db2f8",8052:"b1fd4688",8129:"375d6132",8185:"f5f3cc95",8344:"94d39ab5",8367:"f5747642",8379:"b6667ee4",8383:"db161d53",8392:"f195b151",8442:"61550e81",8479:"3ae247ed",8506:"7354b400",8587:"7a4429d5",8589:"129b4e23",8607:"240e9243",8643:"74106688",8696:"06da91de",8801:"4edc470b",8852:"7c608b34",8894:"ced69189",8897:"67876098",9109:"a5a8475d",9153:"ce466215",9216:"fcd4918e",9237:"85a79252",9329:"7fa260d0",9514:"cc643c59",9613:"9241def9",9620:"4eb5a31e",9637:"4510d538",9683:"500c68ee",9742:"cebfb3c5",9753:"fca7c0a2",9892:"b605de78"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,d)=>Object.prototype.hasOwnProperty.call(e,d),c={},f="redkubes-github-io:",r.l=(e,d,a,b)=>{if(c[e])c[e].push(d);else{var t,o;if(void 0!==a)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var f=c[e];if(delete c[e],t.parentNode&&t.parentNode.removeChild(t),f&&f.forEach((e=>e(a))),d)return d(a)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={10959509:"2704",17896441:"7918",73148982:"1409",98242336:"5290",cce2f323:"12","935f2afb":"53","1e3926cf":"65","9f25d002":"190","2a1f96be":"192","3c6d57b1":"253","5db37859":"344","80cc8fc2":"411",db2fd2f7:"439","9824b3d7":"443",c642c7e8:"512",e4550136:"528",c5c74bfd:"534",c9644b78:"537","99018ea3":"597","0d519d5d":"634",df2434c5:"767",a0650468:"781",a0cf5b3c:"860","1d911987":"912",d53aaf7f:"965","94da8644":"1056","35ac0aef":"1104","4380e181":"1113","1830c2e3":"1195",e2cc03cb:"1241","443e3a65":"1254","6abedfc3":"1369","96d3f3ac":"1390","9cb4274e":"1391",ac482592:"1506",f34c6cc5:"1515",a722ee7a:"1573",c3a9c637:"1576","09735fc0":"1591",c1cd9779:"1658",db4c0e54:"1713","2afdefd3":"1717","69fd0b9a":"1730",be94a9c8:"1854",c42226db:"1872","8213a342":"1882",c9ff9b08:"1913","03eadeb8":"1948","042c512d":"2018","7f5d7fca":"2020","54cc2d4c":"2036","930e985e":"2084","00210a32":"2098","3d235714":"2117","5a2e1e49":"2122",aa3203ff:"2144",e878c199:"2163","1f668492":"2237","7d5c16d7":"2248","9a44d6ca":"2276","5ce65c80":"2280",afd24866:"2370","188da18d":"2430","70b0dc77":"2515","81f8c379":"2552",d8a040d1:"2615",d9893b92:"2668","56d1269f":"2687","14bc3799":"2722","3c110fea":"2780","842ea3d4":"2851",b458a144:"2869","1807f63e":"3056",d673e682:"3120","3b8b7efd":"3121","17a7c5fe":"3126","1df93b7f":"3237","052260a8":"3272","3fd50427":"3418","3ca1c20f":"3458",ab3bc09d:"3474",b4b7b186:"3520",cd151fd5:"3544","21fbcd7c":"3563","13689ae4":"3576","1f918bbd":"3635",c0fcc3ac:"3644",dfc1ee8e:"3927","5f4e8093":"3942",feda9f98:"4011",e6cdbc01:"4027","2f26dbd7":"4041","1a23fb22":"4234",c61e7c1f:"4258","6d553b82":"4321","1d3542c3":"4473","4892c042":"4493",ace391e9:"4505","5c5eecab":"4559","612b9100":"4576","2a3fc902":"4655",d76c6a89:"4717",e7ee1f4e:"4722",cb0338eb:"4724",c3428a3f:"4729",f1abdd8c:"4734",a3cca685:"4791","3a0feb37":"4825",da6d770b:"4875","20c7dd93":"4882",beacde48:"4890","871ddaf7":"5018","2d9c895d":"5022",ca4242f5:"5033",a6ef47a7:"5039",a92bb299:"5092","3379d6c0":"5195","08d2d3ef":"5229",a5fb0fed:"5459",d1ff794b:"5586","942fe4d7":"5616","646a49d4":"5720",b68546d1:"5730","46a4fdf9":"5775","81e06d7e":"5824",f50c0130:"5914",b04270fa:"5920","385dd0a0":"5940","0c3fdeeb":"6096","83b70ecd":"6128","48f8b5b9":"6299",e65ca800:"6306","1691c9ac":"6547",bcbdbf75:"6576",a353273a:"6611","940ad428":"6779",d40b8d5d:"6820",a6a14297:"6866","861ce6bc":"6871",af9df136:"6888","39901f0d":"6906","8924d81d":"6946","4f01d7c7":"7015","7545be8c":"7227","66ebdfe3":"7263","1dcded0d":"7282","6b7c6343":"7365","28c78037":"7386",af8b4e82:"7444",a39a834c:"7498","3765f133":"7514","306a8c6c":"7616","5cecd17a":"7622","270f6692":"7674","08d8079e":"7683",acbd0412:"7763","734d54da":"7778","386e030b":"7878","9ed16ae1":"7896","1a4e3797":"7920","1f25a778":"7927","46be4bcd":"7973","81b812c0":"7980",a47e2810:"7984",c4d36760:"8028","17725d1c":"8052","30f4d83c":"8129",b0500dc6:"8185","1afc8419":"8344","03608398":"8367","3829398f":"8379","246b758f":"8383","0be2dc55":"8392","66c551f1":"8442","12174d43":"8479","9899ea6d":"8506","1fba201f":"8587","8f69df39":"8589","2df7e88d":"8607",b00e4863:"8643","541249eb":"8696","84b718dc":"8801","9b2db8ea":"8852",af477ebb:"8897",e216824f:"9109",ed3faf6d:"9153","5cb822a3":"9216",bde17074:"9237",db897548:"9329","1be78505":"9514",efe7c983:"9613",f80fe6b5:"9620",bb6d4937:"9637","7ea98ab3":"9683",c3394322:"9742","5c500e73":"9753","59a7de32":"9892"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(d,a)=>{var c=r.o(e,d)?e[d]:void 0;if(0!==c)if(c)a.push(c[2]);else if(/^(1303|532)$/.test(d))e[d]=0;else{var f=new Promise(((a,f)=>c=e[d]=[a,f]));a.push(c[2]=f);var b=r.p+r.u(d),t=new Error;r.l(b,(a=>{if(r.o(e,d)&&(0!==(c=e[d])&&(e[d]=void 0),c)){var f=a&&("load"===a.type?"missing":a.type),b=a&&a.target&&a.target.src;t.message="Loading chunk "+d+" failed.\n("+f+": "+b+")",t.name="ChunkLoadError",t.type=f,t.request=b,c[1](t)}}),"chunk-"+d,d)}},r.O.j=d=>0===e[d];var d=(d,a)=>{var c,f,b=a[0],t=a[1],o=a[2],n=0;if(b.some((d=>0!==e[d]))){for(c in t)r.o(t,c)&&(r.m[c]=t[c]);if(o)var i=o(r)}for(d&&d(a);n{"use strict";var e,d,c,a,f,b={},t={};function r(e){var d=t[e];if(void 0!==d)return d.exports;var c=t[e]={id:e,loaded:!1,exports:{}};return b[e].call(c.exports,c,c.exports,r),c.loaded=!0,c.exports}r.m=b,r.c=t,e=[],r.O=(d,c,a,f)=>{if(!c){var b=1/0;for(i=0;i=f)&&Object.keys(r.O).every((e=>r.O[e](c[o])))?c.splice(o--,1):(t=!1,f0&&e[i-1][2]>f;i--)e[i]=e[i-1];e[i]=[c,a,f]},r.n=e=>{var d=e&&e.__esModule?()=>e.default:()=>e;return r.d(d,{a:d}),d},c=Object.getPrototypeOf?e=>Object.getPrototypeOf(e):e=>e.__proto__,r.t=function(e,a){if(1&a&&(e=this(e)),8&a)return e;if("object"==typeof e&&e){if(4&a&&e.__esModule)return e;if(16&a&&"function"==typeof e.then)return e}var f=Object.create(null);r.r(f);var b={};d=d||[null,c({}),c([]),c(c)];for(var t=2&a&&e;"object"==typeof t&&!~d.indexOf(t);t=c(t))Object.getOwnPropertyNames(t).forEach((d=>b[d]=()=>e[d]));return b.default=()=>e,r.d(f,b),f},r.d=(e,d)=>{for(var c in d)r.o(d,c)&&!r.o(e,c)&&Object.defineProperty(e,c,{enumerable:!0,get:d[c]})},r.f={},r.e=e=>Promise.all(Object.keys(r.f).reduce(((d,c)=>(r.f[c](e,d),d)),[])),r.u=e=>"assets/js/"+({12:"cce2f323",53:"935f2afb",65:"1e3926cf",190:"9f25d002",192:"2a1f96be",253:"3c6d57b1",344:"5db37859",411:"80cc8fc2",439:"db2fd2f7",443:"9824b3d7",512:"c642c7e8",528:"e4550136",534:"c5c74bfd",537:"c9644b78",597:"99018ea3",634:"0d519d5d",767:"df2434c5",781:"a0650468",860:"a0cf5b3c",912:"1d911987",965:"d53aaf7f",1056:"94da8644",1104:"35ac0aef",1113:"4380e181",1195:"1830c2e3",1241:"e2cc03cb",1254:"443e3a65",1369:"6abedfc3",1390:"96d3f3ac",1391:"9cb4274e",1409:"73148982",1506:"ac482592",1515:"f34c6cc5",1573:"a722ee7a",1576:"c3a9c637",1591:"09735fc0",1658:"c1cd9779",1713:"db4c0e54",1717:"2afdefd3",1730:"69fd0b9a",1854:"be94a9c8",1872:"c42226db",1882:"8213a342",1913:"c9ff9b08",1948:"03eadeb8",2018:"042c512d",2020:"7f5d7fca",2036:"54cc2d4c",2084:"930e985e",2098:"00210a32",2117:"3d235714",2122:"5a2e1e49",2144:"aa3203ff",2163:"e878c199",2237:"1f668492",2248:"7d5c16d7",2276:"9a44d6ca",2280:"5ce65c80",2370:"afd24866",2430:"188da18d",2515:"70b0dc77",2552:"81f8c379",2615:"d8a040d1",2668:"d9893b92",2687:"56d1269f",2704:"10959509",2722:"14bc3799",2780:"3c110fea",2851:"842ea3d4",2869:"b458a144",3056:"1807f63e",3120:"d673e682",3121:"3b8b7efd",3126:"17a7c5fe",3237:"1df93b7f",3272:"052260a8",3418:"3fd50427",3458:"3ca1c20f",3474:"ab3bc09d",3520:"b4b7b186",3544:"cd151fd5",3563:"21fbcd7c",3576:"13689ae4",3635:"1f918bbd",3644:"c0fcc3ac",3927:"dfc1ee8e",3942:"5f4e8093",4011:"feda9f98",4027:"e6cdbc01",4041:"2f26dbd7",4234:"1a23fb22",4258:"c61e7c1f",4321:"6d553b82",4473:"1d3542c3",4493:"4892c042",4505:"ace391e9",4559:"5c5eecab",4576:"612b9100",4655:"2a3fc902",4717:"d76c6a89",4722:"e7ee1f4e",4724:"cb0338eb",4729:"c3428a3f",4734:"f1abdd8c",4791:"a3cca685",4825:"3a0feb37",4875:"da6d770b",4882:"20c7dd93",4890:"beacde48",5018:"871ddaf7",5022:"2d9c895d",5033:"ca4242f5",5039:"a6ef47a7",5092:"a92bb299",5195:"3379d6c0",5229:"08d2d3ef",5290:"98242336",5459:"a5fb0fed",5586:"d1ff794b",5616:"942fe4d7",5720:"646a49d4",5730:"b68546d1",5775:"46a4fdf9",5824:"81e06d7e",5914:"f50c0130",5920:"b04270fa",5940:"385dd0a0",6096:"0c3fdeeb",6128:"83b70ecd",6299:"48f8b5b9",6306:"e65ca800",6547:"1691c9ac",6576:"bcbdbf75",6611:"a353273a",6779:"940ad428",6820:"d40b8d5d",6866:"a6a14297",6871:"861ce6bc",6888:"af9df136",6906:"39901f0d",6946:"8924d81d",7015:"4f01d7c7",7227:"7545be8c",7263:"66ebdfe3",7282:"1dcded0d",7365:"6b7c6343",7386:"28c78037",7444:"af8b4e82",7498:"a39a834c",7514:"3765f133",7616:"306a8c6c",7622:"5cecd17a",7674:"270f6692",7683:"08d8079e",7763:"acbd0412",7778:"734d54da",7878:"386e030b",7896:"9ed16ae1",7918:"17896441",7920:"1a4e3797",7927:"1f25a778",7973:"46be4bcd",7980:"81b812c0",7984:"a47e2810",8028:"c4d36760",8052:"17725d1c",8129:"30f4d83c",8185:"b0500dc6",8344:"1afc8419",8367:"03608398",8379:"3829398f",8383:"246b758f",8392:"0be2dc55",8442:"66c551f1",8479:"12174d43",8506:"9899ea6d",8587:"1fba201f",8589:"8f69df39",8607:"2df7e88d",8643:"b00e4863",8696:"541249eb",8801:"84b718dc",8852:"9b2db8ea",8897:"af477ebb",9109:"e216824f",9153:"ed3faf6d",9216:"5cb822a3",9237:"bde17074",9329:"db897548",9514:"1be78505",9613:"efe7c983",9620:"f80fe6b5",9637:"bb6d4937",9683:"7ea98ab3",9742:"c3394322",9753:"5c500e73",9892:"59a7de32"}[e]||e)+"."+{12:"2a33b6ac",53:"7cd2029a",65:"4cd8aa47",190:"779054a2",192:"b799d157",253:"22ed9be3",344:"9b4fc439",411:"bdc002d8",439:"5a22fe77",443:"78eb0ad0",512:"142d5454",528:"dbf73ef3",534:"abbfdd1a",537:"7eda6524",597:"1f55f342",634:"0f1de44e",767:"73e04e50",781:"15cc1d5c",860:"f67d241f",912:"fc8668ed",965:"aa118d47",1056:"c33689e0",1104:"dc30eefe",1113:"022d06c3",1195:"2102d558",1241:"3e9007d4",1254:"ae9efd58",1369:"5c5f7b4d",1390:"9ff5acb5",1391:"36753501",1409:"8d276d5c",1506:"89629294",1515:"f6e4afae",1573:"7b212d02",1576:"0276b480",1591:"ac2dd1b6",1658:"f594a6c7",1713:"2f88480b",1717:"a47a00a9",1730:"c2dbc3f6",1854:"9af8a157",1872:"e5705790",1882:"e8bcbc38",1913:"4135aa12",1948:"ee751a12",2018:"81b69616",2020:"044452d9",2036:"704e03a9",2084:"3acf6bf4",2098:"7cdc46ec",2117:"dab34a6e",2122:"9326cc9a",2144:"04779f9f",2163:"93aca584",2237:"3e8a5736",2248:"0d29de02",2276:"16f6b590",2280:"e235d932",2370:"abdb5727",2430:"a38c79ab",2515:"869b8552",2552:"a1c59d23",2615:"8a939763",2668:"ffdba4cf",2687:"e68c91f3",2704:"c06de943",2722:"54b527a9",2780:"baa7b06f",2851:"6d3690f6",2869:"70c0a9d2",3056:"0d30c808",3120:"47198934",3121:"65e3b56a",3126:"04bb0ba9",3237:"b5192427",3272:"91f7c0e9",3418:"7b5f22bf",3458:"ef476d6f",3474:"52a20100",3520:"0e2a4edc",3544:"26596b3b",3563:"1b4c4acb",3576:"5fa63b51",3635:"4e9c014c",3644:"8e6b8ffb",3927:"b788817a",3942:"f6fc3714",4011:"0470c9ef",4027:"260385ee",4041:"502b065a",4234:"2b7f2784",4258:"b2a0890b",4321:"06a915a2",4473:"cd42aa75",4493:"6b7c10eb",4505:"971270f4",4559:"8c3d8ec5",4576:"6ac986db",4655:"bc3dc600",4717:"8ffe54c0",4722:"40e3100f",4724:"d3573256",4729:"60038b89",4734:"5cf402fb",4791:"6b8840f5",4825:"04a4c13c",4875:"de851390",4882:"d115d64e",4890:"f490fbc0",4972:"6875cba6",5018:"1033b43d",5022:"cfb99443",5033:"5c525ac5",5039:"d77eef67",5092:"0185884b",5195:"a6354782",5229:"9e9b0fd4",5290:"af6ab2d9",5459:"eace920b",5586:"0d501801",5616:"99ce5d04",5720:"76bdbf5f",5730:"c975c302",5775:"64d64cb1",5824:"9c895585",5914:"1a54a059",5920:"798381e2",5940:"dc015827",6096:"613977f7",6128:"bf4ada5d",6299:"8cb8529e",6306:"17387992",6547:"7d7250fc",6576:"1a720df3",6611:"128223b0",6779:"c450c81c",6780:"c21aadea",6820:"896345ac",6866:"1734713d",6871:"db0cefc5",6888:"70a31f3d",6906:"d061228f",6945:"bfc572ea",6946:"226f60e1",7015:"f12f572f",7227:"dca04c5e",7263:"aa0c7060",7282:"27541278",7365:"686912f0",7386:"1709a753",7444:"6587e11d",7498:"359b28f3",7514:"e59acb6d",7616:"8650c839",7622:"959856ea",7674:"6844eb90",7683:"a7c6d795",7763:"7876f34a",7778:"a6fb3afa",7878:"2f0e6b91",7896:"e2b5e295",7918:"c4c3429a",7920:"54851adb",7927:"23a53692",7973:"9b2e864d",7980:"bc1af9c9",7984:"d951b317",8028:"3e9db2f8",8052:"b1fd4688",8129:"375d6132",8185:"81ecb920",8344:"94d39ab5",8367:"f5747642",8379:"b6667ee4",8383:"db161d53",8392:"f195b151",8442:"61550e81",8479:"3ae247ed",8506:"7354b400",8587:"7a4429d5",8589:"935e1adc",8607:"240e9243",8643:"74106688",8696:"06da91de",8801:"4edc470b",8852:"7c608b34",8894:"ced69189",8897:"67876098",9109:"a5a8475d",9153:"ce466215",9216:"fcd4918e",9237:"85a79252",9329:"7fa260d0",9514:"cc643c59",9613:"20929ee8",9620:"4eb5a31e",9637:"4510d538",9683:"500c68ee",9742:"cebfb3c5",9753:"fca7c0a2",9892:"b605de78"}[e]+".js",r.miniCssF=e=>{},r.g=function(){if("object"==typeof globalThis)return globalThis;try{return this||new Function("return this")()}catch(e){if("object"==typeof window)return window}}(),r.o=(e,d)=>Object.prototype.hasOwnProperty.call(e,d),a={},f="redkubes-github-io:",r.l=(e,d,c,b)=>{if(a[e])a[e].push(d);else{var t,o;if(void 0!==c)for(var n=document.getElementsByTagName("script"),i=0;i{t.onerror=t.onload=null,clearTimeout(s);var f=a[e];if(delete a[e],t.parentNode&&t.parentNode.removeChild(t),f&&f.forEach((e=>e(c))),d)return d(c)},s=setTimeout(l.bind(null,void 0,{type:"timeout",target:t}),12e4);t.onerror=l.bind(null,t.onerror),t.onload=l.bind(null,t.onload),o&&document.head.appendChild(t)}},r.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.p="/",r.gca=function(e){return e={10959509:"2704",17896441:"7918",73148982:"1409",98242336:"5290",cce2f323:"12","935f2afb":"53","1e3926cf":"65","9f25d002":"190","2a1f96be":"192","3c6d57b1":"253","5db37859":"344","80cc8fc2":"411",db2fd2f7:"439","9824b3d7":"443",c642c7e8:"512",e4550136:"528",c5c74bfd:"534",c9644b78:"537","99018ea3":"597","0d519d5d":"634",df2434c5:"767",a0650468:"781",a0cf5b3c:"860","1d911987":"912",d53aaf7f:"965","94da8644":"1056","35ac0aef":"1104","4380e181":"1113","1830c2e3":"1195",e2cc03cb:"1241","443e3a65":"1254","6abedfc3":"1369","96d3f3ac":"1390","9cb4274e":"1391",ac482592:"1506",f34c6cc5:"1515",a722ee7a:"1573",c3a9c637:"1576","09735fc0":"1591",c1cd9779:"1658",db4c0e54:"1713","2afdefd3":"1717","69fd0b9a":"1730",be94a9c8:"1854",c42226db:"1872","8213a342":"1882",c9ff9b08:"1913","03eadeb8":"1948","042c512d":"2018","7f5d7fca":"2020","54cc2d4c":"2036","930e985e":"2084","00210a32":"2098","3d235714":"2117","5a2e1e49":"2122",aa3203ff:"2144",e878c199:"2163","1f668492":"2237","7d5c16d7":"2248","9a44d6ca":"2276","5ce65c80":"2280",afd24866:"2370","188da18d":"2430","70b0dc77":"2515","81f8c379":"2552",d8a040d1:"2615",d9893b92:"2668","56d1269f":"2687","14bc3799":"2722","3c110fea":"2780","842ea3d4":"2851",b458a144:"2869","1807f63e":"3056",d673e682:"3120","3b8b7efd":"3121","17a7c5fe":"3126","1df93b7f":"3237","052260a8":"3272","3fd50427":"3418","3ca1c20f":"3458",ab3bc09d:"3474",b4b7b186:"3520",cd151fd5:"3544","21fbcd7c":"3563","13689ae4":"3576","1f918bbd":"3635",c0fcc3ac:"3644",dfc1ee8e:"3927","5f4e8093":"3942",feda9f98:"4011",e6cdbc01:"4027","2f26dbd7":"4041","1a23fb22":"4234",c61e7c1f:"4258","6d553b82":"4321","1d3542c3":"4473","4892c042":"4493",ace391e9:"4505","5c5eecab":"4559","612b9100":"4576","2a3fc902":"4655",d76c6a89:"4717",e7ee1f4e:"4722",cb0338eb:"4724",c3428a3f:"4729",f1abdd8c:"4734",a3cca685:"4791","3a0feb37":"4825",da6d770b:"4875","20c7dd93":"4882",beacde48:"4890","871ddaf7":"5018","2d9c895d":"5022",ca4242f5:"5033",a6ef47a7:"5039",a92bb299:"5092","3379d6c0":"5195","08d2d3ef":"5229",a5fb0fed:"5459",d1ff794b:"5586","942fe4d7":"5616","646a49d4":"5720",b68546d1:"5730","46a4fdf9":"5775","81e06d7e":"5824",f50c0130:"5914",b04270fa:"5920","385dd0a0":"5940","0c3fdeeb":"6096","83b70ecd":"6128","48f8b5b9":"6299",e65ca800:"6306","1691c9ac":"6547",bcbdbf75:"6576",a353273a:"6611","940ad428":"6779",d40b8d5d:"6820",a6a14297:"6866","861ce6bc":"6871",af9df136:"6888","39901f0d":"6906","8924d81d":"6946","4f01d7c7":"7015","7545be8c":"7227","66ebdfe3":"7263","1dcded0d":"7282","6b7c6343":"7365","28c78037":"7386",af8b4e82:"7444",a39a834c:"7498","3765f133":"7514","306a8c6c":"7616","5cecd17a":"7622","270f6692":"7674","08d8079e":"7683",acbd0412:"7763","734d54da":"7778","386e030b":"7878","9ed16ae1":"7896","1a4e3797":"7920","1f25a778":"7927","46be4bcd":"7973","81b812c0":"7980",a47e2810:"7984",c4d36760:"8028","17725d1c":"8052","30f4d83c":"8129",b0500dc6:"8185","1afc8419":"8344","03608398":"8367","3829398f":"8379","246b758f":"8383","0be2dc55":"8392","66c551f1":"8442","12174d43":"8479","9899ea6d":"8506","1fba201f":"8587","8f69df39":"8589","2df7e88d":"8607",b00e4863:"8643","541249eb":"8696","84b718dc":"8801","9b2db8ea":"8852",af477ebb:"8897",e216824f:"9109",ed3faf6d:"9153","5cb822a3":"9216",bde17074:"9237",db897548:"9329","1be78505":"9514",efe7c983:"9613",f80fe6b5:"9620",bb6d4937:"9637","7ea98ab3":"9683",c3394322:"9742","5c500e73":"9753","59a7de32":"9892"}[e]||e,r.p+r.u(e)},(()=>{var e={1303:0,532:0};r.f.j=(d,c)=>{var a=r.o(e,d)?e[d]:void 0;if(0!==a)if(a)c.push(a[2]);else if(/^(1303|532)$/.test(d))e[d]=0;else{var f=new Promise(((c,f)=>a=e[d]=[c,f]));c.push(a[2]=f);var b=r.p+r.u(d),t=new Error;r.l(b,(c=>{if(r.o(e,d)&&(0!==(a=e[d])&&(e[d]=void 0),a)){var f=c&&("load"===c.type?"missing":c.type),b=c&&c.target&&c.target.src;t.message="Loading chunk "+d+" failed.\n("+f+": "+b+")",t.name="ChunkLoadError",t.type=f,t.request=b,a[1](t)}}),"chunk-"+d,d)}},r.O.j=d=>0===e[d];var d=(d,c)=>{var a,f,b=c[0],t=c[1],o=c[2],n=0;if(b.some((d=>0!==e[d]))){for(a in t)r.o(t,a)&&(r.m[a]=t[a]);if(o)var i=o(r)}for(d&&d(c);n - +
-

Code of Conduct

Our Pledge​

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards​

Examples of behavior that contributes to a positive environment for our community include:

  • Demonstrating empathy and kindness toward other people
  • Being respectful of differing opinions, viewpoints, and experiences
  • Giving and gracefully accepting constructive feedback
  • Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
  • Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

  • The use of sexualized language or imagery, and sexual attention or advances of any kind
  • Trolling, insulting or derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others' private information, such as a physical or email address, without their explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Enforcement Responsibilities​

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope​

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement​

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at community@redkubes.com. All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Enforcement Guidelines​

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction​

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning​

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban​

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban​

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution​

This Code of Conduct is adapted from the Contributor Covenant, version 2.0, available at v2.0.

Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.

For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

- +

Code of Conduct

Our Pledge​

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards​

Examples of behavior that contributes to a positive environment for our community include:

  • Demonstrating empathy and kindness toward other people
  • Being respectful of differing opinions, viewpoints, and experiences
  • Giving and gracefully accepting constructive feedback
  • Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
  • Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behavior include:

  • The use of sexualized language or imagery, and sexual attention or advances of any kind
  • Trolling, insulting or derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others' private information, such as a physical or email address, without their explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Enforcement Responsibilities​

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope​

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement​

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at community@redkubes.com. All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Enforcement Guidelines​

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction​

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning​

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban​

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban​

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution​

This Code of Conduct is adapted from the Contributor Covenant, version 2.0, available at v2.0.

Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.

For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

+ \ No newline at end of file diff --git a/community/community-values/index.html b/community/community-values/index.html index 993920282..c2046f635 100644 --- a/community/community-values/index.html +++ b/community/community-values/index.html @@ -14,13 +14,13 @@ - +
-

Otomi Community Values

Otomi Community culture contributes substantially to the project's success. The following values (blatantly copied and adopted from kubernetes, as those are almost "universal") are central to this:

Distribution is better than centralization​

The scale of the Otomi project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation. Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstones of our community.

Community over product or company​

We are here as a community first. Our allegiance is to the intentional stewardship of the Otomi project for the benefit of all its members and users everywhere. We support working together publicly for the common goal of a vibrant interoperable ecosystem, providing an excellent experience for our users. Individuals gain status through work. Companies gain status through their commitments to support this community and fund the resources necessary for the project to operate.

Automation over process​

Large projects have a lot of hard yet less exciting work. We value time spent automating repetitive work more highly than toil. Where work cannot be automated, our culture recognizes and rewards all types of contributions while recognizing that heroism is not sustainable.

Inclusive is better than exclusive​

Broadly successful and useful technologies require different perspectives and skill sets, which can only be heard in a welcoming and respectful environment. Community membership is a privilege, not a right. Community members earn leadership through effort, scope, quality, quantity, and duration of contributions. Our community respects the time and effort put into a discussion, regardless of where a contributor is on their growth path.

Evolution is better than stagnation​

Openness to new ideas and studied technological evolution make Otomi a stronger project. Continual improvement, servant leadership, mentorship, and respect are the foundations of Otomi culture. Otomi community leaders have a duty to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up.

"Culture eats strategy for breakfast." --Peter Drucker

- +

Otomi Community Values

Otomi Community culture contributes substantially to the project's success. The following values (blatantly copied and adopted from kubernetes, as those are almost "universal") are central to this:

Distribution is better than centralization​

The scale of the Otomi project is only viable through high-trust and high-visibility distribution of work, which includes delegation of authority, decision making, technical design, code ownership, and documentation. Distributed asynchronous ownership, collaboration, communication and decision making are the cornerstones of our community.

Community over product or company​

We are here as a community first. Our allegiance is to the intentional stewardship of the Otomi project for the benefit of all its members and users everywhere. We support working together publicly for the common goal of a vibrant interoperable ecosystem, providing an excellent experience for our users. Individuals gain status through work. Companies gain status through their commitments to support this community and fund the resources necessary for the project to operate.

Automation over process​

Large projects have a lot of hard yet less exciting work. We value time spent automating repetitive work more highly than toil. Where work cannot be automated, our culture recognizes and rewards all types of contributions while recognizing that heroism is not sustainable.

Inclusive is better than exclusive​

Broadly successful and useful technologies require different perspectives and skill sets, which can only be heard in a welcoming and respectful environment. Community membership is a privilege, not a right. Community members earn leadership through effort, scope, quality, quantity, and duration of contributions. Our community respects the time and effort put into a discussion, regardless of where a contributor is on their growth path.

Evolution is better than stagnation​

Openness to new ideas and studied technological evolution make Otomi a stronger project. Continual improvement, servant leadership, mentorship, and respect are the foundations of Otomi culture. Otomi community leaders have a duty to find, sponsor, and promote new community members. Leaders should expect to step aside. Community members should expect to step up.

"Culture eats strategy for breakfast." --Peter Drucker

+ \ No newline at end of file diff --git a/community/expectations/index.html b/community/expectations/index.html index 994c1b499..cadbf8b35 100644 --- a/community/expectations/index.html +++ b/community/expectations/index.html @@ -14,7 +14,7 @@ - + @@ -24,8 +24,8 @@ This document is intended to be a living one that evolves as the community evolves via the same PR and code review process that shapes the rest of the project. It currently covers the expectations of conduct that govern all members of the community as well as the expectations around code review that govern all active contributors to Otomi.

Code review​

As a community we believe in the value of code review for all contributions. Code review increases both the quality and readability of our codebase, which -in turn produces high quality software.

Consequently, as a community we expect that all active participants in the community will also be active reviewers.

Expectations of reviewers​

Review comments​

Because reviewers are often the first points of contact between new members of the community and can significantly impact the first impression of the Otomi community, reviewers are especially important in shaping the Otomi community. Reviewers are highly encouraged to not only abide by the code of conduct but are strongly encouraged to go above and beyond the code of conduct to promote a collaborative, respectful Otomi community.

Review latency​

Reviewers are expected to respond in a timely fashion to PRs that are assigned to them. Reviewers are expected to respond to an active PRs with reasonable latency, and if reviewers fail to respond, those PRs may be assigned to other reviewers.

Thank you​

We want to thank everyone who contributes their time and effort to making Otomi both a successful endeavour as well as a successful community. The strength of our software lies in the combined strengths of each individual community member. Thanks!

- +in turn produces high quality software.

Consequently, as a community we expect that all active participants in the community will also be active reviewers.

Expectations of reviewers​

Review comments​

Because reviewers are often the first points of contact between new members of the community and can significantly impact the first impression of the Otomi community, reviewers are especially important in shaping the Otomi community. Reviewers are highly encouraged to not only abide by the code of conduct but are strongly encouraged to go above and beyond the code of conduct to promote a collaborative, respectful Otomi community.

Review latency​

Reviewers are expected to respond in a timely fashion to PRs that are assigned to them. Reviewers are expected to respond to an active PRs with reasonable latency, and if reviewers fail to respond, those PRs may be assigned to other reviewers.

Thank you​

We want to thank everyone who contributes their time and effort to making Otomi both a successful endeavour as well as a successful community. The strength of our software lies in the combined strengths of each individual community member. Thanks!

+ \ No newline at end of file diff --git a/community/welcome/index.html b/community/welcome/index.html index b7a4cce3f..13790da88 100644 --- a/community/welcome/index.html +++ b/community/welcome/index.html @@ -14,14 +14,14 @@ - +

Welcome to our community

So you are interested to get involved with Otomi? Awesome! This guide will help you understand the overall organization of the project, and direct you to the best places to get started. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged. All feedback is welcome!

This document is the single source of truth for how to contribute to the following code bases:

  • otomi-core: The heart of Otomi, a monorepo containing all the apps and configurations
  • otomi-tasks: The tasks used by core to massage apps to adhere to the configurations
  • otomi-clients: The openapi generator for the clients used by the tasks

Prerequisites​

Before submitting code to Otomi, you should first complete the following prerequisites. Completing these steps will make your first contribution easier:

Code of Conduct​

Please make sure to read and observe the Code of Conduct and -Community Values

Developer guide​

Effective development starts with an understanding the code structure and the relationship between different components of the system. Read the Code development guide to learn how to develop on Otomi.

Setting up your development environment​

It is not required to set up a developer environment in order to contribute to Otomi, but if you do plan to contribute code changes, follow the instructions in the Developer Docs on how to Set up your development environment.

Community Expectations and Roles​

Otomi is a community project. Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment.

Please read and review the Contribution Expectations for an understanding of code and review expectations.

- +Community Values

Developer guide​

Effective development starts with an understanding the code structure and the relationship between different components of the system. Read the Code development guide to learn how to develop on Otomi.

Setting up your development environment​

It is not required to set up a developer environment in order to contribute to Otomi, but if you do plan to contribute code changes, follow the instructions in the Developer Docs on how to Set up your development environment.

Community Expectations and Roles​

Otomi is a community project. Consequently, it is wholly dependent on its community to provide a productive, friendly and collaborative environment.

Please read and review the Contribution Expectations for an understanding of code and review expectations.

+ \ No newline at end of file diff --git a/docs/apps/alertmanager/index.html b/docs/apps/alertmanager/index.html index 685f2180e..259779ee2 100644 --- a/docs/apps/alertmanager/index.html +++ b/docs/apps/alertmanager/index.html @@ -14,13 +14,13 @@ - +

Alertmanager

Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of de-duplicating, grouping, and routing them to the correct receiver integration such as email, Slack, MS Teams, or OpsGenie. It also takes care of silencing and inhibition of alerts.

Alertmanager is configured to use the global values found under settings' alerts and co-monitoring.

A team may decide to override some or all of them, in order to have alerts sent to their own endpoints. Self-service rights to alerting must be enabled for the team (enabled by default for all teams). When running Otomi in multi-tenant mode, each team is provided a dedicated alertmanger instance.

Otomi supports the following receivers:

  • Slack
  • Microsoft Teams
  • Ops Genie
  • Email
  • (default) None (will use the null receiver to enable the Alertmanger UI).

Configuration values​

Resources​

- + \ No newline at end of file diff --git a/docs/apps/argocd/index.html b/docs/apps/argocd/index.html index ccfcf92d8..02bb2e146 100644 --- a/docs/apps/argocd/index.html +++ b/docs/apps/argocd/index.html @@ -14,13 +14,13 @@ - +

Argo CD

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD is configured by Otomi to use the SSO provided by keycloak, and maps otomi groups to Argo CD roles. The otomi-admin role is made super admin within Argo CD. The team-admin role has access to Argo CD and is admin of all team projects. Members of team roles are only allowed to administer their own projects. All Teams will automatically get access to a Git repo, and Argo CD is configured to listen to this repo. All a team has to do is to fill their repo with intended state, commit, and automation takes care of the rest.

Teams will be be automatically given a git repository in Gitea named team-$teamId-argocd, and Argo CD is automatically configured to access the repository and sync. All that is left to do is for a team-admin (or team member with self-service rights) to fill their repository with intended state and commit.

Argo CD is configured to use the SSO provided by keycloak, and maps Otomi groups to Argo CD roles:

  • Group otomi-admin is made super admin within Argo CD.
  • Group team-admin has access to, and is admin of all team projects.
  • Team members are only allowed access to, and administer their own projects.

Configuration values​

- + \ No newline at end of file diff --git a/docs/apps/certmanager/index.html b/docs/apps/certmanager/index.html index 75156d05e..ab39302e4 100644 --- a/docs/apps/certmanager/index.html +++ b/docs/apps/certmanager/index.html @@ -14,13 +14,13 @@ - +

CertManager

Cert-Manager is used by Otomi to automatically create and rotate wildcard TLS certificates for service endpoints. You may bring your own CA, or let Otomi create one for you. If you bring your own trusted wildcard certificate, then cert-manager will not manage this certificate.

info

The wildcard certificate must be valid for the following domain *.<cluster.domainSuffix>, where the value of <cluster.domainSuffix> comes from the cluster.yaml file.

info

Setting Cert-Manager to use Letsencrypt requires DNS availability of the requesting domains, and forces Otomi to install ExternalDNS. Because a lot of DNS settings are used by other Otomi contexts, all DNS configuration can be found here.

Configuration Values​

The following values can be configured:

ValueDescription
issuerIndicates the origin of the wildcard certificate. Set custom-ca to instruct cert-manager to derive certificate from the customRootCA. Set letsencrypt to instruct cert-manager to request certificate from letsencrypt endpoint. Set byo-wildcard-cert to provide your own wildcard certificate.
customRootCACA that is used to create and verify self-signed certificates. Leave it empty to generate one automatically
customRootCAKeyCA private key that is used to issue certificates. Leave it empty to generate one automatically
byoWildcardCertBring your own trusted wildcard certificate
byoWildcardCertKeyA certificate key corresponding to the byoWildcardCert
emailRequired when using the Let's Encrypt Issuer
stageRequired when using the Let's Encrypt Issuer. Choose between staging or production
resourcesConfigure Request and Limits for cert-manager
- + \ No newline at end of file diff --git a/docs/apps/cloudnativepg/index.html b/docs/apps/cloudnativepg/index.html index 39a1efeae..7934b7d3f 100644 --- a/docs/apps/cloudnativepg/index.html +++ b/docs/apps/cloudnativepg/index.html @@ -14,13 +14,13 @@ - +

Cloudnative Postgresql

CloudNativePG is used by Otomi to provide Postgresql database for Otomi applications like Harbor and Keycloak. In the values you can configure a storageprovider to store backups in (external) object storage. The backups can be enabled in the settings.

- + \ No newline at end of file diff --git a/docs/apps/drone/index.html b/docs/apps/drone/index.html index c722089db..36c3259c7 100644 --- a/docs/apps/drone/index.html +++ b/docs/apps/drone/index.html @@ -14,13 +14,13 @@ - +
- + \ No newline at end of file diff --git a/docs/apps/external-dns/index.html b/docs/apps/external-dns/index.html index ef786a474..213680c92 100644 --- a/docs/apps/external-dns/index.html +++ b/docs/apps/external-dns/index.html @@ -14,13 +14,13 @@ - +

External-DNS

External-dns is required to make public service domains accessible by registering them with Otomi's front loadbalancer CNAME or IP address. When it is not enabled (default) Otomi will instead rely on nip.io to create host names for all services.

The use of external-dns is a prerequisite for using the following features:

  • Harbor private registries for teams
  • Builds (relies on Harbor)
  • Projects (relies on Harbor)
- + \ No newline at end of file diff --git a/docs/apps/falco/index.html b/docs/apps/falco/index.html index 324938799..df6f02992 100644 --- a/docs/apps/falco/index.html +++ b/docs/apps/falco/index.html @@ -14,13 +14,13 @@ - +

Falco

Falco can be used for thread detection. Before activating Falco, please first check which Driver to use. If you know which driver should be selected, activate Falco, go to the Values, select the Driver and submit changes. No Deploy Changes

Configuration values​

Driver settings​

Select the driver to use:

  • module
  • ebpf (default)
  • modern-bpf

Resources​

Adjust default provided resource requests and limits for Falco and Falco Exporter.

Raw values​

When Falco is installed, Otomi will add a set of rules to white-list all known behaviour. These rules are added using the Raw Values.

- + \ No newline at end of file diff --git a/docs/apps/gatekeeper/index.html b/docs/apps/gatekeeper/index.html index ad959291a..8913a7046 100644 --- a/docs/apps/gatekeeper/index.html +++ b/docs/apps/gatekeeper/index.html @@ -14,13 +14,13 @@ - +

Gatekeeper

Otomi offers Kubernetes security best practices through security constraints defined as OPA policies and enforced by Gatekeeper.

Security in-depth​

OPA policies are a replacement for the native PodSecurityPolicies and all defined policies are modeled after the most common psp setups. The Otomi values repository holds a policies.yaml file with sane default presets. The full set of all policies can be found here. Please see the OPA Gatekeeper policy library as it is the source for the policy baseline here. We made a selection of usable policies for Otomi and adapted them to be used by Conftest as well for static analysis of manifests generated by Otomi. YAML Resources are verified against defined .rego policy rules, using the defined preset parameters as their constraint value.

Statical analysis​

Otomi's generated resources are statically evaluated by Conftest before deployment, but also at build time. This gives developers the tools to test their manifests locally, and increases certainty that only valid output will be generated.

Runtime protection​

The same policies are upheld by OPA's Gatekeeper on the cluster during runtime, making sure all deployed resources are approved by it's admission hook.

Modes​

Otomi supports 3 modes:

  1. Enforcing
  2. Permissive (default)
  3. Disabled

In both Enforcing and Permissive mode, individual policies can be switched on or off. By default gatekeeper is enabled in permissive mode (logging & non-blocking)

Customization of the policies is supported based on the Otomi schema (or use Otomi Console). In case of specific requirements, admins can add their own custom policies.

Instructions​

Switching modes​

Gatekeeper by default is disabled. To turn on Gatekeeper by dragging Gatekeeper from the disabled apps section (under Platform/Apps) to the enabled aps section and click on Deploy Changes.

By default Gatekeeper now runs in Permissive mode (the Disable validating webhook is active). To switch to blocking mode, uncheck the Disable validating webhook option:

Gatekeeper modes

Using annotations to bypass policy checks​

It is possible to deviate from the baseline, provided there is a substantiated reason for doing so. To deviate from the baseline, annotations for the pod spec can be configured. Gatekeeper always keeps a log and thus it is traceable when an annotation is used. The use of annotations is a specific Otomi feature.

In order to bypass the policy checks that are enforced by Gatekeeper, Otomi provides an override mechanism to disable or parameterize policy checks by means of annotations. This is based on a gentlemen's approach, and will be RBAC enforced in a future version of Otomi. The policy engine is aware of the following annotations for a pod spec:

annotations:
  policy.otomi.io/ignore: $policy[,$policy2] # pod level ignore for all containers
  policy.otomi.io/ignore-sidecar: $policy[,$policy2] # pod level ignore for sidecars, such as istio-proxy
  policy.otomi.io/ignore.$container: $policy[,$policy2] # ignore for just the mentioned container
  policy.otomi.io/parameters.$policy: '{"extra":"parameters"}'

Parameters will be merged with the default parameters passed to the rule (as defined in the policies.yaml file in the values repo). No override exists for a specific container to provide parameters for.

- + \ No newline at end of file diff --git a/docs/apps/gitea/index.html b/docs/apps/gitea/index.html index f57970b46..bff4433e0 100644 --- a/docs/apps/gitea/index.html +++ b/docs/apps/gitea/index.html @@ -14,13 +14,13 @@ - +

Gitea

Gitea is a community managed lightweight code hosting solution written in Go. Because Otomi uses Tekton to deploy changes to the values repo, it needs a git hosting solution. When no source control is configured, Otomi will deploy Gitea for Tekton to target as a git repo. Gitea may be used for other purposes, and is especially useful in combination with Tekton as a CI/CD solution. Just like Otomi uses it.

- + \ No newline at end of file diff --git a/docs/apps/grafana/index.html b/docs/apps/grafana/index.html index a362ebbc4..e2bb9d67a 100644 --- a/docs/apps/grafana/index.html +++ b/docs/apps/grafana/index.html @@ -14,13 +14,13 @@ - +

Grafana

Otomi uses Grafana to visualize Prometheus metrics and Loki logs. Team members are automatically given Editor role, while admins are also given Admin role. It is possible to make configuration changes directly in Grafana, but only to non-conflicting settings. Data sources are preconfigured and must not be edited as changes will be lost when Grafana is redeployed.

- + \ No newline at end of file diff --git a/docs/apps/harbor/index.html b/docs/apps/harbor/index.html index 992782383..1e4867e39 100644 --- a/docs/apps/harbor/index.html +++ b/docs/apps/harbor/index.html @@ -14,13 +14,13 @@ - +

Harbor

Harbor is an open-source registry that secures artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. As a CNCF graduated project, Harbor delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud-native compute platforms like Kubernetes. (source: https://goharbor.io/)

Automation​

Otomi runs the following automation tasks:

  • Creating a project in Harbor for each team
  • Creating a bot-account for each team
  • Creating a Kubernetes pull secret in the team namespace to enable pulling of images out of the local registry
  • Creating a Kubernetes push secret in the team namespace that can be downloaded (if enabled) by team members to push images to a private repo

Known issues​

Docker login​

Unfortunately Harbor has not yet delivered a user friendly mechanism for users to interface with their registry via docker cli. To use docker cli one has to login with the registry EVERY time before using the cli. At the same time this fails when one is not logged into the Harbor dashboard beforehand. In order to login without issues one has to follow these steps:

  • ONLY ONCE: get the cli secret from the Harbor dashboard (via User Profile).
  • refresh Harbor dashboard web view (this will refresh the OIDC auth token)
  • docker login using the cli secret as password: docker login harbor.<cluster-domain> -u < User_Name > -p <CLI secret>
  • do your docker pull/push etc within the token TTL window (60 secs)

Usually this is not a problem as team users don't pull or push these images directly. We are working on solving this, and expect to have a fix soon.

OIDC: conflicting user​

Problem:

Error while logging in to harbor with OIDC: Conflict, the user with same username or email has been onboarded..

Cause:

By redeploing keycloak the same user gets a new sub claim in openid scope. Harbor uses sub and iss claims in order to match them to a user from its database (see: subiss column at oidc_user table in registry database). If the same user identifies with a new sub then harbor tries to create a new entry in the harbor_user database table and it fails on the username column uniqueness constraint.

Solution:

Please check up on this link when this problem occurs, because a fix might already be released: goharbor/harbor#13674. If so, please create a PR to fix this in the otomi-core repo, or create an issue there. Otherwise continue:

Connect to the database service

kh exec harbor-database-0 -it -- psql -U postgres

Select the registry database

\c registry

Find out the <user_id>

SELECT user_id FROM harbor_user WHERE username = '<user name>';

Remove the user from the database

DELETE FROM oidc_user WHERE user_id = <userid>;
DELETE FROM harbor_user WHERE user_id = <userid>;

Exit psql

\q

Try to login once again and observe that you are asked to confirm your username.

Pod multi-attach error​

Problem

Kubernetes cannot schedule the harbor-harbor-registry Pod.

Cause

Multi-Attach error occurs for persistent volumes that support only one writer at a time.

Solution

Delete an existing harbor registry replicaset. Note that this operation makes registry temporarely unavailable.

- + \ No newline at end of file diff --git a/docs/apps/ingress-nginx/index.html b/docs/apps/ingress-nginx/index.html index 5cfb13840..377ba8e7c 100644 --- a/docs/apps/ingress-nginx/index.html +++ b/docs/apps/ingress-nginx/index.html @@ -14,13 +14,13 @@ - +

NGINX Ingress

Ingress NGINX is the default ingress controller in Otomi and part of the core setup (this means it is not possible use another controller within Otomi).

Using the OWASP rule set​

The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts. The CRS provides protection against many common attack categories, including SQL Injection, Cross Site Scripting, Local File Inclusion, etc.

The OWASP rule set can only be enabled when ModSecurity is enabled. Read more about the OWASP rule set here

Automation​

Teams will be be automatically given a git repository in Gitea named team-$teamId-argocd, and Argo CD is automatically configured to access the repository and sync. All that is left to do is for a team-admin (or team member with self-service rights) to fill their repository with intended state and commit.

Integrations​

Otomi integrated NGINX Ingress Controller into an advanced ingress architecture.

Instructions​

Using ModSecurity​

By default, ModSecurity is not enabled in Nginx. To turn on ModSecurity, go to the values tab of the app. Under Mod security click enabled.

When enabled, ModSecurity by default is configured in blocking mode. This can have a negative impact on your application. First turn blocking off and adjust the applications accordingly. Teams can see all ModSecurity warnings using Grafana. A shortcut for this dashboard is allready preconfigured.

The default modesecurity snipped added to the Nginx configuration contains the following defaults:

modsecurity-snippet: |
    SecAuditEngine RelevantOnly
    SecAuditLogParts ABDEFHIJZ
    SecAuditLogFormat JSON
    SecAuditLogType Serial
    SecAuditLog /dev/stdout
    SecRequestBodyLimit 1073741824
    SecRuleRemoveById 920350

To change the modsecurity configuration, use Raw values. Here is an overview of all the configuration directives.

- + \ No newline at end of file diff --git a/docs/apps/istio/index.html b/docs/apps/istio/index.html index 4ac482b2b..e06afc64c 100644 --- a/docs/apps/istio/index.html +++ b/docs/apps/istio/index.html @@ -14,14 +14,14 @@ - +

Istio

Since Otomi has security best practices built in, it is designed for intrusion. Istio is installed by Otomi as a service mesh to deliver the following capabilities:

  • mTLS enforcement for all traffic that is deemed compromisable
  • egress control, forcing teams to choose explicit egress endpoints
  • advanced routing capabilities such as weight based load balancing (A/B or blue/green testing)

In the future we might make it possible to opt out of Istio, but that effectively nullifies the mTLS capabilities and egress control.

Known issues​

Stale Keycloak JWKS cache​

Problem

Jwks doesn't have key to match kid or alg from Jwt

Cause The istio-proxy sidecar caches JWKS with a TTL of 20 minutes. The TTL is a hardcoded parameter (JwtPubKeyRefreshInterval) and cannot be configured. By redeploing keycloak kid or alg can change, thus JWKS that is cached by istio-proxy sidecar is not valid anymore.

Solution Either wait 20 minutes, so JWKS is refreshed or kill all pods that are referenced by a RequestAuthentication resource. All services that have authz.workload set will have one (see: core.yaml).

Istio log errors​

When you see errors in the logs like such:

error    authorization    skipped rule ns[monitoring]-policy[grafana-dev-eks-otomi-cloud]-rule[0]: :authority must not be used in TCP

These are not real errors, but logged incorrectly: https://github.com/istio/istio/issues/24701#issuecomment-649719089

- + \ No newline at end of file diff --git a/docs/apps/jaeger/index.html b/docs/apps/jaeger/index.html index 312a47f49..ebdbc0849 100644 --- a/docs/apps/jaeger/index.html +++ b/docs/apps/jaeger/index.html @@ -14,13 +14,13 @@ - +

Jaeger

Jaeger can be activated by Otomi to gain tracing insights on its network traffic. It runs in anonymous mode and each authenticated user is given the same authorization, allowing them to see everything. In the future this may be limited according to scope such as role and teams.

- + \ No newline at end of file diff --git a/docs/apps/keycloak/index.html b/docs/apps/keycloak/index.html index d445dd468..16b33314d 100644 --- a/docs/apps/keycloak/index.html +++ b/docs/apps/keycloak/index.html @@ -14,13 +14,13 @@ - +

Keycloak

The SSO login page for Otomi is served by Keycloak. It is used as an identity broker or provider for all Otomi integrated applications. Keycloak is configured with mappers that normalize incoming identities from an IDP to have predictable claims format to be used by Otomi applications.

Keycloak is automatically configured with 3 roles:

  • otomi-admin: super admin role for all platform configuration and core applications
  • team-admin: team admin role to manage teams and users
  • team: team role for team members

Group (team) membership is reflected in the user's 'groups' claim. When this authorization configuration is useful to their own built applications, teams can directly use Keycloak's provided groups and roles claims. There is no need for a client or token validation, as that has been done by the platform. They can do so by turning on the "Authenticate with Single Sign On" checkbox. This then limits the application access to only allow the members of the team.

When there are different requirements to use Keycloak for business applications, Keycloak's designated "master" and "otomi" realms may not be used, and an additional realm needs to be created. We refer to the keycloak docs for any custom configuration targeting business applications.

Instructions​

Create a user in Keycloak​

To create users in Keycloak, follow these steps:

  1. Open the Keycloak app
  2. Click on Administration Console
  3. Login with admin credentials (using otomi-admin user and password provided in the installer log or the otomi.adminPassword provided in the initial values)
  4. Select the Otomi realm
  5. Click on Users then Add user
  6. Fill in a user name in the Username field
  7. Fill in your email address in the Email field
  8. Select Email verified
  9. Click Join Groups
  10. Add the user to the required group (Team)
  11. Click Create
  12. Choose the Credentials tab and then Set password
  13. Fill in a password
  14. Optional: Make te password Temporary. This requires the user to change the password at the first login
  15. Click on "Save"
  16. Click Save password
- + \ No newline at end of file diff --git a/docs/apps/kiali/index.html b/docs/apps/kiali/index.html index 5d70ffe67..22a7d491e 100644 --- a/docs/apps/kiali/index.html +++ b/docs/apps/kiali/index.html @@ -14,13 +14,13 @@ - +

Kiali

Kiali can be activated in Otomi to gain observability insights on its network traffic. It runs in anonymous mode and each authenticated user is given the same authorization, allowing them to see everything. In the future this may be limited according to scope such as role and teams.

- + \ No newline at end of file diff --git a/docs/apps/knative/index.html b/docs/apps/knative/index.html index f12e90814..9f68d9e2b 100644 --- a/docs/apps/knative/index.html +++ b/docs/apps/knative/index.html @@ -14,13 +14,13 @@ - +

Knative

Knative can be activated in Otomi to deliver Container-as-a-Service (CaaS) functionality with scale-to-zero possibility. It can be compared to Functions-as-a-service (FaaS) but is container oriented, and takes only one manifest to configure an autoscaling service based on a container image of choice. Otomi uses Istio Virtual Services under the hood to route traffic coming in for a public domain to its backing Knative Service, allowing to set a custom domain.

- + \ No newline at end of file diff --git a/docs/apps/loki/index.html b/docs/apps/loki/index.html index f08c1868b..b012cf61e 100644 --- a/docs/apps/loki/index.html +++ b/docs/apps/loki/index.html @@ -14,13 +14,13 @@ - +

Loki

Loki aggregates all the container logs from the platform and stores them in a storage endpoint of choice (defaults to PVC). When Otomi is installed in multi-tenancy mode (see here) it will split logs from team namespaces and make them available only to team members. Otomi provides shortcuts to selections of logs based on interest. Otomi splits logs per team, installs a dedicated Grafana instance per team and configures authentication for Grafana to allow access for team members only.

Known issues​

Time Range does not show all data​

Unfortunately the Grafana team has not yet solved their long running problems with their LogQL interface. Instead of providing paginated queries to Loki, it is needed to provide a "line limit" by the user manually.

In a data driven application that has pagination, when a user selects a time window for a data query, the user will not have to provide additional information to perform that query. The UI application takes responsibility for instrumenting the query towards its data backend. It should thus load & render the results either through pagination or by scrolling the time range into view.

Solution:

When you don't see enough data, try increasing the line limit. The maximum is configurable in the Loki values.

- + \ No newline at end of file diff --git a/docs/apps/minio/index.html b/docs/apps/minio/index.html index b218fd222..32aa09a44 100644 --- a/docs/apps/minio/index.html +++ b/docs/apps/minio/index.html @@ -14,13 +14,13 @@ - +

Minio

Minio can be enabled to provice an in-cluster S3 compatible Object Store service. Minio is by default provisioned to be used by:

  • Loki (for storing logs)
  • Thanos (for storing metrics)
  • Velero (for storing backups)
  • Cloudnative-pg (for storing database backups)
  • Tempo (for storing traces)
- + \ No newline at end of file diff --git a/docs/apps/otel/index.html b/docs/apps/otel/index.html index 2f6ab5e8c..f6dd86483 100644 --- a/docs/apps/otel/index.html +++ b/docs/apps/otel/index.html @@ -14,13 +14,13 @@ - +

Open Telemetry Operator

OpenTelemetry Operator is used to create an OTEL Collector to receive telemetry data from Istio and Nginx Ingress (and applications configured with Instrumentation) and export this data to the Tempo backend. Grafana can then be used to see traces.

- + \ No newline at end of file diff --git a/docs/apps/prometheus/index.html b/docs/apps/prometheus/index.html index 1d08e601c..098568525 100644 --- a/docs/apps/prometheus/index.html +++ b/docs/apps/prometheus/index.html @@ -14,13 +14,13 @@ - +
- + \ No newline at end of file diff --git a/docs/apps/tekton/index.html b/docs/apps/tekton/index.html index 2a251f5a0..2964c3911 100644 --- a/docs/apps/tekton/index.html +++ b/docs/apps/tekton/index.html @@ -14,13 +14,13 @@ - +

Tekton

Tekton is used in Otomi for the Builds self-service. When a Build is created, Otomi generates the Tekton Pipeline and Pipelinerun resources. There are 2 types op pipelines:

  • Docker for building images based on a Dockerfile
  • Buildpacks for building images using buildpacks

When Tekton is activated, Otomi will add 3 Tekton tasks to the team's namespace:

  1. Buildpacks
  2. git-clone
  3. kaniko

and use them in the pipelines.

Automation​

  • When activated, the Tekton Helm chart will be installed
  • When a team is created and Tekton is active, Tekton tasks used by the pipelines will be added to the team namespace
  • When a build is created, the required pipeline and pipelinerun resources are created

Instructions​

When Otomi generates the manifest resources for the pipeline and the pipelinerun, the pipelinerun will automatically run the pipeline once. Use the following command to check if the status of the pipelinerun:

tkn pipelineruns logs  <name-of-the-pipelinerun> -n team-<team name>

If the build is changed in Otomi, the pipelinerun will not be re-started. Use the following command to start the pipeline after a change:

tkn pipeline start <name-of-the-pipeline>  --use-pipelinerun <name-of-the-pipelinerun>  -n team-<team name>
- + \ No newline at end of file diff --git a/docs/apps/thanos/index.html b/docs/apps/thanos/index.html index c0f5a9d6c..19460b4ae 100644 --- a/docs/apps/thanos/index.html +++ b/docs/apps/thanos/index.html @@ -14,13 +14,13 @@ - +
- + \ No newline at end of file diff --git a/docs/apps/trivy/index.html b/docs/apps/trivy/index.html index 17b189bbf..1f891c683 100644 --- a/docs/apps/trivy/index.html +++ b/docs/apps/trivy/index.html @@ -14,13 +14,13 @@ - +

Trivy Operator

Trivy can be enabled to scan all running containers in all team namespaces. When enabled, the team's Grafana instance will be configured to provide a dashboard for teams to see all vulnerabilities within their applications.

- + \ No newline at end of file diff --git a/docs/apps/vault/index.html b/docs/apps/vault/index.html index 6e0f701a1..7794e9988 100644 --- a/docs/apps/vault/index.html +++ b/docs/apps/vault/index.html @@ -14,14 +14,14 @@ - +

Hashicorp Vault

note

Hashicorp Vault is being deprecated. The Otomi Secrets feature is soon going to be based on SealedSecrets.

HashiCorp Vault is a shared application for securely storing and managing secrets. Read more about Vault here. Vault has been made tenant aware in Otomi. When it is enabled, a space will automatically be created for each team, and only team members are allowed access. Vault is automatically configured to use Otomi's Keycloak OIDC settings to login users through Otomi's SSO.

Vault (like all parts of Otomi) runs natively on Kubernetes. To prevent data from Vault being lost during a rolling cluster upgrade, data persistence can be configured in combination with external (blob) storage. Read more here for configuring external data persistence.

Instructions​

Sign in with full access​

If you would like to sign in into Vault with full access (and not with limited access provided by Otomi), you need to:

  1. Get the token
kubectl get secret -n vault vault-unseal-keys -o jsonpath='{.data.vault-root}' | base64 -d | pbcopy

  1. Open Vault and sign in with method token

  2. Paste the token generated in step 1.

- + \ No newline at end of file diff --git a/docs/apps/velero/index.html b/docs/apps/velero/index.html index f74f32a97..27d383c37 100644 --- a/docs/apps/velero/index.html +++ b/docs/apps/velero/index.html @@ -14,13 +14,13 @@ - +

Velero

Velero can be activated for creating backups of PVC's and Kubernetes resources.

Configuration​

Azure​

Velero in Otomi uses the Velero plugin for Microsoft Azure. To setup Velero in Azure, follow the instructions here. Note that Otomi only supports the use of Service Principals.

AWS​

Velero in Otomi uses the Velero plugin for AWS. To setup Velero in AWS, follow the instructions here.

Instructions​

To start using Velero, follow these steps:

  1. Activate the Velero app by dragging the app to the activated apps section.
  2. Click on the app en go to the Values tab
  3. Select the provider used for your Kubernetes cluster
  4. Fill in the required fields
  5. Go to Settings and select Backup
  6. Select the preferred backup schedule (platform and/or team) and optionally change the settings
  7. Click Deploy Changes

Velero will now be installed and the backup schedules will be created. Check the cloud storage endpoint to see if the backups have been created.

Optionally install the Velero cli.

- + \ No newline at end of file diff --git a/docs/for-ciso/overview/index.html b/docs/for-ciso/overview/index.html index 601c67e24..42c83c6a3 100644 --- a/docs/for-ciso/overview/index.html +++ b/docs/for-ciso/overview/index.html @@ -14,13 +14,13 @@ - +

Overview

ISO 27001 controls checklist​

This section is for the Chief Information Security Officer (CISO) to provide insights into all ISO 27001 controlls implemented in Otomi. This information can be used in case of an (internal/external) security audit to provide proof that all applications run on a secure and ISO 27001 compliant platform.

Controls list​

info

Comming soon!

- + \ No newline at end of file diff --git a/docs/for-devs/console/apps/index.html b/docs/for-devs/console/apps/index.html index de64811a6..784588107 100644 --- a/docs/for-devs/console/apps/index.html +++ b/docs/for-devs/console/apps/index.html @@ -14,13 +14,13 @@ - +

Team Apps

The team apps are shared apps on the platform available for teams to use. Click on the app to open the app, or click on the configuration icon to go to the app details:

Info​

Here you will find more information about the app and how the app is integrated into Otomi.

Shortcuts​

Create shortcuts to open the app at a target path. Created shortcuts will also become visable in the Shortcuts section.

- + \ No newline at end of file diff --git a/docs/for-devs/console/builds/index.html b/docs/for-devs/console/builds/index.html index 3cce7b9fc..34586eb5b 100644 --- a/docs/for-devs/console/builds/index.html +++ b/docs/for-devs/console/builds/index.html @@ -14,13 +14,13 @@ - +

Team Builds

A Build in Otomi is a self-service feature for building OCI compliant images based on application source code.

info

Ask your platform administrator to activate Harbor to use this feature.

Builds (all)​

All Builds of the team are listed here.

Team builds

PropertyDescription
NameThe name of the build
TypeType of the build. buildpacks or docker
Webhook urlThe copy to clipboard webhook URL if a trigger is configured for the build
TektonLink to the `PipelineRun`` of the build in the Tekton dashboard
RepositoryThe copy to clipboard repository name of the image
TagThe tag of the image
StatusThe status of the Build. If the Build has failed. click on the Tekton link to see more details

Create a build​

  1. Enter a name for the build

The name of the build will be used for the registry name of the image (harbor.<domainSuffix>/team-name/build-name)

  1. (optional) Adjust the tag

The tag will be used to tag the image (harbor.<domainSuffix>/team-name/build-name:tag)

Now choose the type of the build:

  • Use Docker to build an image using the ./Dockerfile in your code repository
  • Use Buildpacks to build an image from application source using Buildpacks

Docker​

  1. Add the URL of the repository that contains the application source code.
  2. (optional) Change the path of the Dockerfile. Default is ./Dockerfile. To use a Dockerfile is a specific folder, use ./folder/Dockerfile.
  3. (optional) Change the revision. This can be a commit, a tag, or a branch.
  4. (Optional) Select External Repo if the repository used for the Build is not a public or a private Git repo in the local Gitea. When selected, fill in the secret name that contains the required SSH credentials. Read more here about how to setup SSH authentication with your Git provider.
  5. (optional) Select to create an event listener to trigger the build based on a Gitea webhook.

Buildpacks​

  1. Add the URL of the Git repository that contains the application source code
  2. (optional) Add the path. This is a subpath within the repo where the source to build is located
  3. (optional) Change the revision. This can be a commit, a tag, or a branch
  4. (optional) Add Environment variables to set during build-time
  5. (Optional) Select External Repo if the repository used for the Build is not a public or a private Git repo in the local Gitea. When selected, fill in the secret name that contains the required SSH credentials. Read more here about how to setup SSH authentication with your Git provider.
  6. (optional) Select to create an event listener to trigger the build based on a Gitea webhook.

Build status details​

To see the more status details of the build, click on the PipelineRun link of the build in the list of builds. If a trigger is configured, the link will show all PipelineRuns.

Configure a webhook for the Git repo in Gitea​

  1. In Otomi Console, click on apps the left menu and then open Gitea
  2. In the top menu of Gitea, click on Explore and then on the green repo
  3. Go to Settings (top right) and then to Webhooks
  4. Click Add Webhook and select Gitea
  5. In the Target URL, paste the webhook URL from your clipboard.
  6. Click Add Webhook

Expose the trigger listener publicly​

When using an external (private) Git repository, the trigger event listener that is created by Otomi can also be exposed publicly. To expose the event listener publicly:

  1. Go to Services
  2. Click create new service
  3. Select the el-gitea-webhook-<build-name> internal service
  4. Under Exposure, select External
  5. Click Submit and the Deploy Changes

Restart a build​

To restart a build:

  • Start a shell in the console
  • run the following command:
tkn pipelineruns list
tkn pipelinerun logs <pipelinerun-name> -f

Build can be restarted by changing the tag of the build or by restarting the pipeline manually:

  • Start/open a shell in the console
  • run the following command:
tkn pipelines list
tkn pipeline start <pipeline-name> --use-pipelinerun <pipelinerun-name>
- + \ No newline at end of file diff --git a/docs/for-devs/console/catalog/index.html b/docs/for-devs/console/catalog/index.html index 845c50b0c..16ceb532b 100644 --- a/docs/for-devs/console/catalog/index.html +++ b/docs/for-devs/console/catalog/index.html @@ -14,13 +14,13 @@ - +

Otomi Catalog

The Catalog is a library of curated Helm charts to create Kubernetes resources. By default the Catalog contains a set of Helm charts provided by Otomi to get started quickly, but they can also be modified depending on your requirements or be removed from the Catalog.

The contents of the Catalog and the RBAC configuration (which Team can use which Helm chart) are managed by the platform administrator. Contact the platform administrator if you would like to add your own charts to use within your Team.

About Otomi Catalog quick starts​

The Catalog contains a set of Helm charts that can be used as quick starts. The following quick starts are available:

k8s-deployment​

The otomi-quickstart-k8s-deployment Helm chart can be used to create a Kubernetes Deployment (to deploy a single image), a Service and a ServiceAccount. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap can be created.

k8s-deployment-otel​

The otomi-quickstart-k8s-deployment-otel Helm chart can be used to create a Kubernetes Deployment (to deploy a single image), a Service, a ServiceAccount and an Instrumentation resource. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap can be created.

k8s-deployments-canary​

The otomi-quickstart-k8s-deployments-canary Helm chart can be used to create 2 Kubernetes Deployments (to deploy 2 versions of an image), a Service and a ServiceAccount resource. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap (for each version) can be created.

knative-service​

The otomi-quickstart-knative-service Helm chart can be used to create a Knative Service (to deploy a single image), a Service and a ServiceAccount. Optionally a Prometheus ServiceMonitor can be created.

Otomi quick start for creating a PostgreSQL cluster​

The otomi-quickstart-postgresql Helm chart can be used to create a cloudnativepg PostgreSQL Cluster. Optionally a Prometheus PodMonitor and a Configmap (for adding a postgresql dashboard to Grafana) can be created.

Otomi quick start for creating a Redis master-replica cluster​

The otomi-quickstart-redis Helm chart can be used to create a Redis master-replica cluster.

Using the Catalog​

  1. Click on Catalog in the left menu

  2. You will now see all the templates that are available to use

catalog

  1. Click on the k8s-deployment template

catalog

In the Info tab you'll see some information about the Chart like the version and additional instructions.

  1. Click on the Values tab

catalog

  1. Continue to create a workload
- + \ No newline at end of file diff --git a/docs/for-devs/console/dashboard/index.html b/docs/for-devs/console/dashboard/index.html index ae7095711..2479ba600 100644 --- a/docs/for-devs/console/dashboard/index.html +++ b/docs/for-devs/console/dashboard/index.html @@ -14,13 +14,13 @@ - +

Team Dashboard

The team dashboard gives a global overview of information most relevant to the team.

Prerequisites​

The Team dashboard uses the Team's Grafana instance to get it's information from. Make sure Grafana is enabled for the team. To enable Grafana:

  • Go to Settings
  • Managed monitoring
  • Enable Grafana

Dashboard elements​

The dashboard has 5 elements

Team dashboard

Inventory​

The inventory shows the Otomi resources within the team. Click on an inventory item to go directly to the full list.

Resource Status​

The Resource Status panels show if there are any issues with Pods deployed by the team.

Resource Utilization​

The Resource Utilization panels show the total amount of CPU and Memory consumed by the team.

Vulnerabilities​

The Vulnerabilities panels show the total amount of LOW, MEDIUM, HIGH and CRITICAL vulnerabilities in running containers deployed by the Team.

Compliance​

The Compliance panel shows the total amount of policy violations in workloads deployed by the Team.

- + \ No newline at end of file diff --git a/docs/for-devs/console/deploy-changes/index.html b/docs/for-devs/console/deploy-changes/index.html index 935d1032d..5bfe88887 100644 --- a/docs/for-devs/console/deploy-changes/index.html +++ b/docs/for-devs/console/deploy-changes/index.html @@ -14,13 +14,13 @@ - +

Deploy changes

When a form (build, workload, service, backup, secret) is submitted, Otomi will prepare a commit in the Otomi Values Git repository. When the commit is prepared, the Deploy Changes button in the top of the left menu will become active. To commit your changes, click on the Deploy Changes button.

- + \ No newline at end of file diff --git a/docs/for-devs/console/projects/index.html b/docs/for-devs/console/projects/index.html index 44107db90..d1f442a79 100644 --- a/docs/for-devs/console/projects/index.html +++ b/docs/for-devs/console/projects/index.html @@ -14,13 +14,13 @@ - +

Team Projects

A Project in Otomi is a collection of a Build, a Workload and a Service in ONE form.

Create a Project​

  1. In the left menu click on Projects and then on Create project.
  2. Provide a name for the project.

Note: The name of the project will be used for all created otomi resources (build, workload and service).

  1. Select Create build form source or Use an existing image
  2. If Create build from source is selected: follow the instruction for creating a Build
  3. If Use an existing image is selected: follow the instruction for creating a Workload

Note: The image.repository and image.tag parameters in the values of the workload are automatically set when Create build form source is used. If Use an existing image is selected, the image.repository and image.tag parameters need to be set manually.

  1. Follow the instruction for creating a Service to expose the workload
  2. Click Submit and then Deploy changes
- + \ No newline at end of file diff --git a/docs/for-devs/console/secrets/index.html b/docs/for-devs/console/secrets/index.html index 05d554096..e018bc7ef 100644 --- a/docs/for-devs/console/secrets/index.html +++ b/docs/for-devs/console/secrets/index.html @@ -14,13 +14,13 @@ - +

Team Secrets

Any secret that is created here should have it's counterpart in Vault by the same name. Otomi will create kubernetes secrets from those Vault secrets. These can then be used in Otomi Services and Otomi Workloads, as injected env vars, or as file mounts.

Otomi supports 3 types of secrets:

info

Ask you platform administrator to activate Hashicorp Vault to be able to use this feature.

Create a Generic secret​

Create a generic kubernetes secret by listing a selection of (or all) properties of a Vault secret registered with the same name.

Create a Docker Registry secret​

The docker registry (or pull) secret should exist in Vault as a secret with the same name. The vault secret should be of type "json" and have only one property .dockerconfigjson. Use the following command to create the json:

email="not@us.ed" # can be something else if the registry provider expects it, but usually this is ignored
server="" # example: "https://harbor.demo.eks.otomi.cloud/"
username="" # your username
password="" # your password, can be token
kubectl create secret docker-registry --dry-run=client regcred --docker-email=$email --docker-server=$server --docker-username=$username --docker-password=$password -o jsonpath='{.data.\.dockerconfigjson}' | base64 --decode

Create a TLS secret​

To create a TLS secret, the fields should correspond with the properties as named in the Vault secret registered with the same name. The "ca" field is optional and can be used to provide the certificate authority (for mTLS).

SettingDescriptionDefault
crtThe property name pointing to the PEM encoded public key certificate in Vaulttls.crt
keyThe property name pointing to the private key certificate content in Vaulttls.key
caThe property name pointing to the CA certificate content in Vault (optional)ca.crt
- + \ No newline at end of file diff --git a/docs/for-devs/console/services/index.html b/docs/for-devs/console/services/index.html index ccdbf58f1..5d8eed102 100644 --- a/docs/for-devs/console/services/index.html +++ b/docs/for-devs/console/services/index.html @@ -14,13 +14,13 @@ - +

Team Services

A service in Otomi is a self-service feature for:

  • Publicly exposing ClusterIP services. Otomi will automatically create and configure all ingress resources needed, including Istio Virtual Services and Gateways, certificates, DNS records and Oauth2 proxy for Single Sign On
  • Private (in-cluster) exposure of ClusterIP services
  • Configure network policies

Services (team <team-name>)​

All Services of the team are listed here.

Team services

PropertyDescription
Service NameThe name of the service
Ingress classThe ingress class configured. This is the ingress controller that exposes the service
URLThe URL of the service if the service is configured for external exposure
StatusThe status of the service

Create a Service​

First select the (ClusterIP) service to use.

Configuring traffic control​

The traffic control option allows to split traffic between multiple deployed versions of the same app (blue-green, canary). Note that the traffic control can only be used when:

  • There are 2 versions deployed that share a single service

  • The service is configured for external exposure

  • Select Enabled to configure traffic control

  • Fill in the weight for the 2 versions. A 50/50 weight can be used for blue/green. A 90/10 weight can be used for canary.

Configuring exposure (ingress)​

Exposure controls wether internet exposure should be enabled or not. Three options exist:

  • Private: choose to expose services in-cluster
  • Public: choose to expose services on a private or public load balancer

Private​

Choose private to expose the service in-cluster and configure in-cluster ingress network policies

External​

Use External to expose a service with a domain name and a certificate on an external network (using an external load balancer).

A URL will have a hostname that consists of $HOST_NAME.$DNS_ZONE. Options are described below.

SettingDescription
Ingress class nameThe ingress class to assing this service to. Select one of the available classes
TLS passthroughPass through the request as is to the backing service
Use suggested domainThe suggested domain is the team domain for which a wildcard certificate already exists. Has the team name in it
HostChoose a hostname that will be the prefix of the domain
Forward pathDo not "terminate" the path but instead pass it to the receiving service
DNS ZoneChoose a dns zone that will be the suffix of the domain
Authenticate with Single Sign OnForwards any unauthenticated traffic to the Keycloak login page, which might forward to an external IDP
Already has a certificateDon't generate certificates for this service
> Certificate ARN[AWS only] Provide the certificate ARN
> Select existing secret name[non AWS] Provide a TLS secret name previously created under Secrets. Override to select name of secret not known here
HTTP Response HeadersHTTP Response headers that will be set on the exposed service

Use CNAME​

Select Use CNAME when the URL of the service is used as a value in a CNAME.

With TLS Termination at the NGINX Controller​

Follow the steps below to set up a CNAME when the TLS termination happens on the NGINX controller.

  1. Configure a CNAME entry with your domain name provider.
  2. Generate or copy your domain certificates and store them as a TLS secret in your team's namespace.
  3. Go to the service configuration section in the Otomi Console.
  4. Create a new service by selecting the k8s service and port that you want to expose.
  5. Check the "Use CNAME" checkbox. Two text boxes will appear: "domain" and "tlsSecretName".
  6. Fill in both text boxes accordingly. Example: domain=demo.example.com, tlsSecretName=my-cname-cert.
  7. Click on the "Submit" button, followed by the "Deploy" button.

With TLS Termination at the Application (Pod) Level​

Follow the steps below to set up a CNAME when the TLS termination happens on the application (pod) running on the cluster. It is expected that the certificates are already embedded or mounted in the application/pod.

  1. Configure a CNAME entry with your domain name provider.
  2. Go to the service configuration section in the Otomi Console.
  3. Create a new service by selecting the k8s service and port that you want to expose.
  4. Check the "TLS Passthrough" checkbox.
  5. Check the "Use CNAME" checkbox. Fill the domain field(leave the tlsSecretName field empty).
  6. Provide your cname domain in the text box.
  7. Click on the "Submit" button, followed by the "Deploy" button.

Configure network policies​

Ingress traffic inside the cluster​

When the network policies option is enabled for the team all traffic to the service (from other services within the team and from services in other teams) is set to Deny all by default. To allow other services to access the service, select Allow traffic from selected team services and specify the Team and Service name of the services that is allowed to access the service. It is also possible to allow traffic from all Team Services. In this case select Allow traffic from all team services.

External egress filtering​

Traffic to external endpoints (outside of the cluster) is denied by default. To allow egress traffic to external endpoints, add the FQDN or IP address of the endpoint, the target port and the protocol used.

- + \ No newline at end of file diff --git a/docs/for-devs/console/settings/index.html b/docs/for-devs/console/settings/index.html index 9cbb0c912..701a39c87 100644 --- a/docs/for-devs/console/settings/index.html +++ b/docs/for-devs/console/settings/index.html @@ -14,13 +14,13 @@ - +

Team Settings

Based on self-service options allowed by the platfrom administrator, team members can change the settings of their team.

Configure OIDC group mapping​

note

The OIDC group mapping will only be visible when Otomi is configured with an external Identity Provider (IdP).

Change the OIDC group-mapping to allow access based on group membership.

Managed monitoring​

Activate a (platform) managed Grafana, Prometheus or Alertmanager instance for the team. The installed Grafana, Prometheus and Alertmanager will be monitored by the Platform administrator.

Grafana​

Enable to install a Grafana instance for the team.

Dependencies:

  • The Grafana instance is automatically configured with a datasource for the Team's Prometheus.
  • If Loki (for logs) is enabled on the Platform, Grafana needs to be enabled here.
  • Grafana is provisioned with multiple dashboards that rely on the Platform Prometheus. If Prometheus on the Platform is not enabled, these dashboards will not work!

Prometheus​

Enable to install a Prometheus instance for the team. The Prometheus instance is configured to only scrape metrics from PodMonitors and ServiceMonitors that have the label prometheus: team-<team-name>.

Alertmanger​

Enable to install an Alertmanager instance for the team. The Alertmanger instance will only show alerts based on Rules from the Team's Prometheus.

Configure alert settings​

note

Alerts settings will only be active when Alertmanager is enabled for the team.

Change the alert settings and preferred notification receivers.

OptionDescription
SlackNeeds a slack webhook url that will give alerts for warnings and criticals
Microsoft TeamsNeeds two alerting endpoints, for both warnings as well as criticals
EmailYou may provide a list of email addresses for both 'Non Critical' and 'Critical'
If none selectedGlobal (admin) alerting endpoint configuration will be used

Configure Resource Quotas​

When required, add resource quota for the team. The resource quota should adhere to the "spec.hard" format as described here.

Note

There is no validation as there is no schema published. Add/change resource quota at your own risk.

Configure Azure Monitor​

note

Configuring Azure Monitor settings will only be active when cluster.provider=azure.

Azure Monitor is the platform service that provides a single source for monitoring Azure resources.

OptionDescription
No Azure monitoring-
Azure monitoring with global settingsTakes on the global settings
Azure monitoring with custom settingsOverrides any global settings

Configure Network Policies​

OptionDescription
Network policiesWhen enabled team services will be bound by (ingress) network policies
Egress controlWhen enabled team service egress traffic will be limited to pre-defined endpoints only

Team self service flags​

The self-service flags (what is a team allowed to) can only be configured by an admin user.

Service​

OptionPermission
IngressThe Team is allowed to configure External Exposure for a Service
Network policyThe team is allowed to configure network (ingress and egress) for a Service

Team​

OptionPermission
AlertsThe Team is allowed to configure Alert settings for the team
Billing alert quotasThe team is allowed to configure Billing alert quotas for the team
OIDCThe team is allowed to configure the OIDC group mapping for the team
Resource quotasThe team is allowed to configure resource quotas for the team
Download kube configThe team is allowed to download the Kube Config
Download docker configThe team is allowed to download the Docker Config
Network policyThe team is allowed to the Network policy configuration for the team
- + \ No newline at end of file diff --git a/docs/for-devs/console/shell/index.html b/docs/for-devs/console/shell/index.html index de809563b..12ba20f9b 100644 --- a/docs/for-devs/console/shell/index.html +++ b/docs/for-devs/console/shell/index.html @@ -14,13 +14,13 @@ - +

Shell (TTY Console)

The Shell feature allows to start a web based shell in Console with Kube API access. When starting a shell, a dedicated shell instance will be started for the user. The shell includes the following tools:

When running the shell as a member of a team, the shell will allow only provide acccess to resources in the team namespace.

The Shell provides an easy and efficient way to access and manage Kubernetes resources directly from your browser, eliminating the need for complex VPN setups or external tools. This guide will walk you through the steps of using the TTY Console effectively:

  • Simplified Access: Access your Kubernetes cluster without the hassle of VPNs or additional tools.
  • Identity-Based Access: Leverage your group membership from an Identity Provider, such as Azure AD, for secure access to your Kubernetes namespace.
  • Efficient Interface: Utilize essential Kubernetes management tools and perform tasks seamlessly.

Using the Shell​

  1. Log in into the Otomi Console
  2. Click on the "Shell" option in the left menu.
  3. You'll be connected to the TTY Console interface, granting direct access to the Kubernetes namespace of the Team.

Basic Commands and Shortcuts​

  • Utilize the kubectl command to interact with your Kubernetes cluster
  • Benefit from the convenient k shortcut for kubectl with bash-completion

Integrated CLI tools​

The Shell comes with a set of integrated CLI tools:

  • k9s: Gain insights into your Kubernetes resources with an intuitive UI
  • Tekton ClI: Monitor Project pipelines efficiently
  • Other Tools: Tools like jq, yq, and curl are at your disposal for enhanced functionality

Working with Tmux​

  • If you're a Tmux enthusiast, enjoy the ability to create multiple windows and panes for multitasking
  • This feature enhances your productivity by allowing you to organize your workspace effectively

Session Management​

Browser Crash Resilience​

  • The TTY Console is designed to be resilient in the face of browser crashes
  • If your browser unexpectedly crashes, your session remains intact
  • You can simply reopen the browser and resume your Kubernetes management tasks

Ending Sessions​

  • When you're finished with your Kubernetes management tasks, remember to properly end your session by clicking the recycle bin button on the top right of the TTY window. This will delete your session
  • Logging out of your session will have the same effect
- + \ No newline at end of file diff --git a/docs/for-devs/console/shortcuts/index.html b/docs/for-devs/console/shortcuts/index.html index e12888b04..3854480f1 100644 --- a/docs/for-devs/console/shortcuts/index.html +++ b/docs/for-devs/console/shortcuts/index.html @@ -14,13 +14,13 @@ - +
- + \ No newline at end of file diff --git a/docs/for-devs/console/workloads/index.html b/docs/for-devs/console/workloads/index.html index 804505815..a4d2cdf14 100644 --- a/docs/for-devs/console/workloads/index.html +++ b/docs/for-devs/console/workloads/index.html @@ -14,13 +14,13 @@ - +

Team Workloads

A Workload in Otomi is a self-service feature for creating Kubernetes resources using Helm charts from the Otomi Developer Catalog.

Workloads (all)​

All Workloads of the team are listed here.

Team workloads

PropertyDescription
NameThe name of the workload
ArgocdLink to the Argo CD application in the Argo CD UI
Image update strategyThe configured update strategy for the workload
StatusThe status of the workload. Click on the Argo CD application link to see more status details

Create a Workload​

Before creating a workload from the developer catalog, we'll need the repository and tag of the image you would like to use.

  1. Go to the list of Builds and add the repository of the build to use to your clipboard. Remember the tag.

  2. Go to Workloads in the left menu and click on New Workload

  3. Select a template from the catalog to use

  4. Add a Name for the workload

  5. (Optional) Configure the Auto image updater. Default is Disabled.

The Auto Image Updater will (based on the update strategy) automatically update the container images of a workload.

Select the update strategy. Choose between:

  • Digest: Inspects a single tag in the registry for changes, and updates the image on any change to the previous state. Requires to provide a repository and a tag.
  • Semver: Update based on semantic versions. Example: v1.0 would allow the image to be updated to any patch version within the 1.0 minor release.

There are 2 other properties available: imageParameter and tagParameter. Change the parameters in case your Helm application contains more than one image in the manifests or uses another parameters to define which image to render in the manifests.

  1. In the workload values, change the following parameters:
image:
  repository: <paste from clipboard>
  tag: latest
  1. Click Submit

Now click on Deploy Changes

After a few minutes, Otomi will have created all the needed Argo CD resources to deploy your workload. In the workloads list, click on the Application link of your workload to see the status of your workload.

The values of a workload can be changed at any time. Changes will automatically be deployed.

- + \ No newline at end of file diff --git a/docs/for-ops/cli/apply/index.html b/docs/for-ops/cli/apply/index.html index 863048d3c..22b77a953 100644 --- a/docs/for-ops/cli/apply/index.html +++ b/docs/for-ops/cli/apply/index.html @@ -14,13 +14,13 @@ - +

otomi apply

otomi apply [options]

Description​

Apply Kubernetes resources. Without any options it will (re)deploy the full stack. With -l or -f it will apply only the defined resources

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/bash/index.html b/docs/for-ops/cli/bash/index.html index 05a746d1e..50dcdc0d8 100644 --- a/docs/for-ops/cli/bash/index.html +++ b/docs/for-ops/cli/bash/index.html @@ -14,13 +14,13 @@ - +
- + \ No newline at end of file diff --git a/docs/for-ops/cli/bootstrap/index.html b/docs/for-ops/cli/bootstrap/index.html index a842a38e6..4ef4ecf66 100644 --- a/docs/for-ops/cli/bootstrap/index.html +++ b/docs/for-ops/cli/bootstrap/index.html @@ -14,13 +14,13 @@ - +

otomi bootstrap

otomi bootstrap [options]

Description​

Bootstrap values repository with artifacts corresponding to the cluster's stack version

Options​

OptionDescriptionValue TypeDefault
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/check-policies/index.html b/docs/for-ops/cli/check-policies/index.html index d96803c10..2f0dcaa35 100644 --- a/docs/for-ops/cli/check-policies/index.html +++ b/docs/for-ops/cli/check-policies/index.html @@ -14,13 +14,13 @@ - +

check-policies

otomi check-policies [options]

Description​

Check if generated manifests adhere to defined OPA policies.

Options​

OptionDescriptionValue TypeDefault
-l, --labelSelect charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileSelect helmfiles by filename, e.g. -f helmfile.d/helmfile-15.ingress-core.yaml[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/commit/index.html b/docs/for-ops/cli/commit/index.html index a7e954d20..4a4789703 100644 --- a/docs/for-ops/cli/commit/index.html +++ b/docs/for-ops/cli/commit/index.html @@ -14,13 +14,13 @@ - +

otomi commit

otomi commit [options]

Description​

Generate pipelines, and commit changes to the values repository

Options​

OptionDescriptionValue TypeDefault
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
--ni, --non-interactiveSame as setting env.CI[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/decrypt/index.html b/docs/for-ops/cli/decrypt/index.html index f087477a8..8f2e96b0d 100644 --- a/docs/for-ops/cli/decrypt/index.html +++ b/docs/for-ops/cli/decrypt/index.html @@ -14,13 +14,13 @@ - +

otomi decrypt

otomi decrypt [options]

Description​

Decrypts file(s), given as arguments, or any file matching secrets.*.yaml in the values repository

Options​

OptionDescriptionValue TypeDefault
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
--ni, --non-interactiveSame as setting env.CI[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/deploying/index.html b/docs/for-ops/cli/deploying/index.html index f0790dc3b..817f8a54d 100644 --- a/docs/for-ops/cli/deploying/index.html +++ b/docs/for-ops/cli/deploying/index.html @@ -14,13 +14,13 @@ - +

Using Otomi CLI

1. Initialize a values repo​

Otomi needs a git repo to store its configuration. We call it a values repo.

In order to quickly get up and running it is advised to download the chart values and fill in the values.

The following commands bootstrap the values repo:

# map the chart values.yaml as initial input:
export VALUES_INPUT=$PWD/values.yaml
# point to a folder that is or will become the values repo
export ENV_DIR=$PWD/otomi-values
# and bootstrap all the files in there
otomi bootstrap

2. Customize configuration​

The essential otomi platform configurations is stored in env/cluster.yaml, env/settings.yaml and env/secrets.settings.yaml files. Inspect them and customize values to match your environment.

note

The minimum required input is found in the chart values.

3. Configure credentials from a KMS (optional)​

No encryption needed?

If you don't need encryption straight away please continue to the next step

Otomi will encrypt any secrets.*.yaml files with sops, but only if it finds sops: configuration details. In order to have access to the KMS credentials to encrypt/decrypt, a .secrets file needs to exist and have those credentials. Please copy .secrets.sample .secrets and fill it in with the credentials from the prerequisites.

Then you can run otomi bootstrap, which will result in the encryption and decryption of the secrets files.

Note to developers:

To allow git diff to show unencrypted values, you must register the sops diffing routine once with git. To register it:

git config diff.sopsdiffer.textconv 'sops -d'

This only registers the sops differ, which is responsible for invoking sops. But sops still needs the credentials to the KMS service. Again, your AWS profile is always pointed and loaded, but in case of Google KMS you will need to point GOOGLE_APPLICATION_CREDENTIALS to the gcp-key.json file holding your account information:

export GOOGLE_APPLICATION_CREDENTIALS=$PWD/gcp-key.json

Now try a diff:

git diff

4. Start Otomi Console on your local machine (optional)​

Bootstrap again and start the console:

otomi bootstrap
otomi console

The console allows for easy configuration of many settings but not all. Assuming the setup steps are completed, you need to now configure the Otomi values repository. This repo is the source configuration for Otomi.

5. Configuration​

Configuration can be performed much easier through the Otomi Console, so please refer to the Otomi Console documentation.

However, chart configuration is not (yet) exposed through the console, so please look at the values repo's env/charts/* files to edit the configuration files.

Important things to note:

  • Every configuration file can have a secrets.*.yaml counterpart, but these are optional.
  • A json schema and vscode settings are imported by the bootrap (in .vscode/*), so you will have automatic linting and hinting for the configuration when vscode is used (try CTRL+SPACE in the yaml).
  • If .secrets is correctly configured then automatic de-/en-cryption will also be performed when in vscode and editing a secrets.*.yaml file.

Please follow the guidance of the yaml hinting, as it has all the descriptions and example values you need to operate on these files.

Otomi YAML hinting only works in vscode

VSCode automatically loads the '.vscode/values-schema.yaml' schema provided. Please inspect it or wire it up manually when using another editor.

If you wish to be sure of your changes, you can always do a git diff. When you chose to use encryption and have correctly followed the corresponding instructions, then you should see a diff with the unencrypted values. That is, if you modified any ;)

6. Validation​

When you are done with the configuration you can validate the results:

otomi validate-values

If you have made an error in the format of the values this will be reported.

To check if all the output manifests are valid for the target cluster's k8s version, and following best practices you can run another variation:

otomi validate-templates

7. Deployment​

Charted vs uncharted resources​

The output manifests generated by otomi are deployed in two ways:

  • Uncharted: some base manifests are applied directly with kubectl apply
  • Charted: manfests that are packaged up in helm charts.

Ideally, we would like to deploy as helm chart as it has many benefits such as rollback. But in some cases we can't or we don't wish to. The reasons for that are the following:

  1. Some resources we don't want governed by charts (as charts might get accidentally removed, erasing everything that was deployed with it).
  2. Some existing resources have to be patched (like pull secrets in service accounts), which helmfile won't do as it will not modify existing resources not annotated to be under control by a chart.
  3. Some resources need to exist before the charts are deployed (such as CRDs).

The manifests that are currently not charted are:

  • k8s/base (unparameterized, mostly rbac roles)
  • values/cloud (applies cloud specific "normalization" patterns, such as for storageclasses)
  • values/k8s (team resources, such as namespaces, service accounts, pull secrets)

Working with uncharted resources​

Currently we don't have any subcommand that only works on uncharted resources, but we have the following commands that target the entire bundle.

  • otomi test: does a dry run, showing all manifests that will be deployed, and will also show any errors in the output manifests.
  • otomi apply: deploys all the manifests (uncharted first, then charted)

So after doing otomi test, if all looks ok, go ahead and do the initial deployment of all resources:

otomi apply

This command executes two stages (please see binzx/apply.ts). The first stage will deploy all uncharted resources with kubectl apply, and the second stage will deploy all the charted resources with helmfile apply.

Whenever you add a team, or change or add to these uncharted resources, you have to run otomi apply to apply them. When you let Drone do the syncing for you, it will invoke that command to synchronize the cluster.

Working with charted resources​

During development iterations you will probably not touch uncharted resources often, but instead you will add features in charts.

Otomi has these subcommands that only target charted resources:

otomi (diff|apply|sync|template)

You can always target a single chart like this:

otomi (diff|apply|sync|template) -l name=prometheus-operator

(For a list of all supported flags to use those subcommands, we defer to the helmfile documentation, as those are deferred to the helmfile cli.)

Let's do a diff of all the charts that are enabled:

otomi diff

Need to know quirks​

Whenever you modify resources without using helm, its internal bookkeeping (the versioned secrets in the namespaces) will not change, and any subsequent otomi apply commands will not modify anything. If you notice this, and want to overwrite with the output manifests, you can use otomi sync, which will skip doing a diff, and instead apply all charted manifests as a new version.

8. Committing values​

To commit values and run post processing tasks:

otomi commit

This will detect any version changes and then commit all files with a standardized message "Manual commit". (We believe all values repo configuration changes are equally meaningful and don't need explicit commit messages.) Directly doing a git commit is discouraged with a git hook saying so, but whenever you did not touch any versions in env/clusters.yaml you may bypass with git commit -m "Manual commit" --no-verify to save development time.

- + \ No newline at end of file diff --git a/docs/for-ops/cli/destroy/index.html b/docs/for-ops/cli/destroy/index.html index e0a6d97a0..9dbf8e286 100644 --- a/docs/for-ops/cli/destroy/index.html +++ b/docs/for-ops/cli/destroy/index.html @@ -14,13 +14,13 @@ - +

otomi destroy

otomi destroy [options]

Description​

Destroy all, or supplied, K8S resources

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/diff/index.html b/docs/for-ops/cli/diff/index.html index 8765dafd9..f0e9adcf3 100644 --- a/docs/for-ops/cli/diff/index.html +++ b/docs/for-ops/cli/diff/index.html @@ -14,13 +14,13 @@ - +

otomi diff

otomi diff [options]

Description​

Diff all, or supplied, K8S resources.

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/encrypt/index.html b/docs/for-ops/cli/encrypt/index.html index 8ff4e7bc6..0e1f52d18 100644 --- a/docs/for-ops/cli/encrypt/index.html +++ b/docs/for-ops/cli/encrypt/index.html @@ -14,13 +14,13 @@ - +

otomi encrypt

otomi encrypt [files...] [options]

Description​

Encrypts file(s), given as arguments, or any file matching secrets.*.yaml in the values repository

Options​

OptionDescriptionValue TypeDefault
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
--ni, --non-interactiveSame as setting env.CI[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/installation/index.html b/docs/for-ops/cli/installation/index.html index db424f5ef..6ebd77060 100644 --- a/docs/for-ops/cli/installation/index.html +++ b/docs/for-ops/cli/installation/index.html @@ -14,13 +14,13 @@ - +

Installing and using Otomi CLI

Prerequisites​

  • Docker
  • Bash v4

Otomi CLI only supports bash versions greater than 4. Install or upgrade on Mac OS:

brew install bash

Install the CLI​

Installer script​

# Using wget
wget -O- https://git.io/otomi-cli-installer | bash
# Using curl
curl -L https://git.io/otomi-cli-installer | bash

Manual installation​

Using wget​

# Using wget
wget https://git.io/otomi-cli -O otomi && chmod +x otomi
# Using curl
curl https://git.io/otomi-cli -o otomi && chmod +x otomi

This will download otomi into the current directory

Using the CLI​

Running any otomi command will pull the values' otomi.version image tag.

The image used is rather large, so this might take some time.

The total compressed size of the base image with all the tools in use is close to 1Gi, and shows close to 2Gi uncompressed.

To use the CLI you can run:

otomi --help

To find the options available.

Command Reference​

CommandDescription
otomi applyApply all, or supplied, K8S resources
otomi bashRun interactive bash shell in otomi-core container
otomi bootstrapBootstrap values repo with artifacts corresponding to the cluster's stack version
otomi check-policiesCheck if generated manifests adhere to defined OPA policies
otomi commitExecute wrapper for generate pipelines -> git commit changed files
otomi decrypt [files..]Decrypts file(s), given as arguments, or any file matching secrets.*.yaml in the values repository
otomi destroyDestroy all, or supplied, K8S resources
otomi diffDiff all, or supplied, K8S resources
otomi encrypt [files..]Encrypts file(s), given as arguments, or any file matching secrets.*.yaml in the values repository
otomi lintUses helmfile lint to lint the target manifests
otomi pullWrapper for git pull && otomi bootstrap
otomi rotate-keysRotate keys for all the sops secrets in the values repository
otomi statusShow cluster status
otomi syncSync all, or supplied, K8S resources
otomi template [outDir]Export all, or supplied, K8S resources
otomi testRun tests against the target cluster
otomi validate-templatesValidate generated manifests against supported k8s versions/CRDs and best practices
otomi validate-valuesValidate values for each cluster against JSON schema (takes target options)
otomi valuesShow helmfile values for target cluster
otomi xExecute command in container
- + \ No newline at end of file diff --git a/docs/for-ops/cli/known-issues/index.html b/docs/for-ops/cli/known-issues/index.html index ea3ab10d7..0a3ce2ff7 100644 --- a/docs/for-ops/cli/known-issues/index.html +++ b/docs/for-ops/cli/known-issues/index.html @@ -14,13 +14,13 @@ - +

Known Issues

The otomi (diff|apply|sync|template) commands are delegated to helmfile, which in turn delegates the deployment work to helm. Sometimes it is not clear wether the issue is from Helm or Helmfile, so we will address them together in this section.

State drift​

Problem: otomi apply does not seem to change resources.

Solution: try otomi sync

Background info:

The otomi apply command uses helmfile's apply command, which combines its diff and sync commandds. So it first does a helmfile diff against helm's bookeeping (which resides in versioned secrets, e.g. sh.helm.release.v1.loki.v1). This is the most cost effective way and does not lead to a new release version being deployed when there are no changes. However, when you changed cluster resources without the Otomi CLI (so without using helm) this is not reflected in the secrets. helmfile diff will not see any changes in the secret, so it won't execute the subsequent helmfile sync. If you wish to overwrite the desired state on the cluster, use the otomi sync -l name=$releaseName command directly. Usually only for a certain release, so you don't force change all the releases, which costs a lot of time.

Deployment errors/problems​

Helmfile uses Helm 3 under the hood, and it will throw errors in certain situations:

1. It can't deploy a resource when it already exists​

When a resource already exists and was not deployed with the chart before (alien to Helm), it is possible to 'adopt' the resource beforehand by labeling and annotating them correctly:

k -n $NS annotate --overwrite $KIND $NAME meta.helm.sh/release-name=$RELEASE
k -n $NS annotate --overwrite $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE
k -n $NS label --overwrite $KIND $NAME app.kubernetes.io/managed-by=Helm

This functionality exists in the stack in bin/upgrades/adopt-by-helm.sh, and is used in the upgrade scripts.

2. Release's latest state is failed​

Error: "$releaseName" has no deployed releases

This may happen when you try to install a chart (usually for the first time) and it fails. This results in the release's deployment having state 'failed'.

Solution:

  • When this was the first install: destroy with otomi destroy -l name=$releaseName and then apply with otomi apply -l name=$releaseName again.
  • When it was successfully deployed before: remove the last versioned helm secret that is causing the blockage (e.g. sh.helm.release.v1.loki.v3)

3. Some resources couldn't be patched​

Error: UPGRADE FAILED: failed to replace object: ... field is immutable

This usually happens when a manifest is not allowed to be patched in place and needs to be replaced. Retry the borking release with otomi apply -l name=$releaseName --extraArgs='--force=true' which does exactly that.

4. Timeout​

Problem: Sometimes the Otomi cli will time out when operating on a Google cluster.

Cause: This happens when the containerized kubectl binary wants to refresh an access token, but it can't find the binary that was registered to do so in the otomi docker container.

Workaround: Retry the command. Before every invocation with the containerized kubectl binary, Otomi CLI first runs kubectl version with the local binary to invoke a token refresh, resulting in an up-to-date config to mount.

Background:

The Otomi CLI is a docker container with all the binaries it needs to deploy to these clusters. When running a command the local cloud configs are mounted. These configs may contain configuration for token refresh mechanisms, including the name of a binary to execute with certain parameters. This makes it possible to include the binaries in the image, and make them available via the known $PATH.

However, Google Cloud SDK breaks with that approach, by tightly coupling a hard path to the local gcloud binary. Sample user section from $KUBECONFIG:

- name: gke_otomi-cloud_europe-west4_otomi-gke-demo
  user:
    auth-provider:
      config:
        access-token: xxxxxxxxx
        cmd-args: config config-helper --format=json
        cmd-path: /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/gcloud
        expiry: '2020-10-29T02:15:37Z'
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

This will not work with containerization unfortunately. We also can't predict the path on the users host computer to this binary, so we have to hope for Google to fix this some day. They are not inclined to do so it seems:

https://issuetracker.google.com/issues/171493249

Maybe they will start to see the importance of this after getting more feedback ;)

5. It can't deploy when another operation is in progress​

Problem: The otomi apply or otomi sync command fails with the following error:

Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress

Cause: A given helm release is in pending-upgrade state, e.g.:

NAME      NAMESPACE    REVISION    UPDATED                 STATUS     CHART      APP VERSION
keycloak    keycloak    3        2021-03-22 13:50:22.5069506 +0000 UTC  pending-upgrade keycloak-8.2.2 10.0.0

Solution: Find helm release that is in the pending-upgrade state:

helm list -a -A | grep -i pending

If there is a helm release in the pending state AND it has more than one revision, then rollback to the previous revision:

helm -n <namespace> rollback <release-name> <previous revision number>

Otherwise, if there is a helm release in the state pending AND it has only one revision, then remove that release:

helm uninstall -n <namespace> <release-name>
- + \ No newline at end of file diff --git a/docs/for-ops/cli/lint/index.html b/docs/for-ops/cli/lint/index.html index e4bc3ef3e..f6a757cc9 100644 --- a/docs/for-ops/cli/lint/index.html +++ b/docs/for-ops/cli/lint/index.html @@ -14,13 +14,13 @@ - +

otomi lint

otomi lint [options]

Description​

Uses helmfile lint to lint the target manifests

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/pull/index.html b/docs/for-ops/cli/pull/index.html index a15e68b99..1962d1d50 100644 --- a/docs/for-ops/cli/pull/index.html +++ b/docs/for-ops/cli/pull/index.html @@ -14,13 +14,13 @@ - +

otomi pull

otomi pull [options]

Description​

Wrapper for git pull and otomi bootstrap. It pulls the latest values and bootstraps the missing values.

Options​

OptionDescriptionValue TypeDefault
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
--ni, --non-interactiveSame as setting env.CI[boolean]false
-v, --verbosecount
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/rotate-keys/index.html b/docs/for-ops/cli/rotate-keys/index.html index 0e2aa5d61..3ea0e4994 100644 --- a/docs/for-ops/cli/rotate-keys/index.html +++ b/docs/for-ops/cli/rotate-keys/index.html @@ -14,13 +14,13 @@ - +

otomi rotate-keys

otomi rotate-keys [options]

Description​

Rotate keys for all the sops secrets in the values repository

Options​

OptionDescriptionValue TypeDefault
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
--ni, --non-interactiveSame as setting env.CI[boolean]false
-v, --verbosecount
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/status/index.html b/docs/for-ops/cli/status/index.html index 4c058a351..c2c803893 100644 --- a/docs/for-ops/cli/status/index.html +++ b/docs/for-ops/cli/status/index.html @@ -14,13 +14,13 @@ - +

otomi status

otomi status [options]

Description​

Show the status of the cluster and the deployed charts

Options​

OptionDescriptionValue TypeDefault
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
--ni, --non-interactiveSame as setting env.CI[boolean]false
-v, --verbosecount
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/sync/index.html b/docs/for-ops/cli/sync/index.html index bbb10cba7..ce242e256 100644 --- a/docs/for-ops/cli/sync/index.html +++ b/docs/for-ops/cli/sync/index.html @@ -14,13 +14,13 @@ - +

otomi sync

otomi sync [options]

Description​

Synchronize all, or supplied, K8S resources

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/template/index.html b/docs/for-ops/cli/template/index.html index 96ed1eef8..dcf4b7769 100644 --- a/docs/for-ops/cli/template/index.html +++ b/docs/for-ops/cli/template/index.html @@ -14,13 +14,13 @@ - +

otomi template

otomi template [options]

Description​

Export all, or supplied, K8S resources

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/test/index.html b/docs/for-ops/cli/test/index.html index 3cfb6cd03..194a40e2c 100644 --- a/docs/for-ops/cli/test/index.html +++ b/docs/for-ops/cli/test/index.html @@ -14,13 +14,13 @@ - +

otomi test

otomi test [options]

Description​

Run tests against the target cluster

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/validate-templates/index.html b/docs/for-ops/cli/validate-templates/index.html index 339009e6d..b13d34f9a 100644 --- a/docs/for-ops/cli/validate-templates/index.html +++ b/docs/for-ops/cli/validate-templates/index.html @@ -14,13 +14,13 @@ - +

otomi validate-templates

otomi validate-templates [options]

Description​

Validate generated manifests against supported K8S versions/CRDs and best practices

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/validate-values/index.html b/docs/for-ops/cli/validate-values/index.html index a833274a7..b11e10318 100644 --- a/docs/for-ops/cli/validate-values/index.html +++ b/docs/for-ops/cli/validate-values/index.html @@ -14,13 +14,13 @@ - +

otomi validate-values

otomi validate-values [options]

Description​

Validate values for each cluster against JSON schema (takes target options).

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/values/index.html b/docs/for-ops/cli/values/index.html index 66a5808ef..964e07ca2 100644 --- a/docs/for-ops/cli/values/index.html +++ b/docs/for-ops/cli/values/index.html @@ -14,13 +14,13 @@ - +

otomi values

otomi values [options]

Description​

Show helmfile values for target cluster

Options​

OptionDescriptionValue TypeDefault
-l, --labelHelmfile option to select charts by label (format: <label>=<value>), e.g. -l name=prometheus-operator or --label group=jobs[array]
-f, --fileHelmfile option to select helmfiles by filename, e.g. '-f helmfile.d/helmfile-15.ingress-core.yaml'[array]
--log-levelfatal, error, warn, info, verbose, debug, tracewarn
-s, --skip-cleanup[boolean]false
-v, --verbosecount
--ni, --non-interactiveSame as setting env.CI[boolean]false
-h, --helpShow help
- + \ No newline at end of file diff --git a/docs/for-ops/cli/x/index.html b/docs/for-ops/cli/x/index.html index 74b15d4c3..6a62a0eac 100644 --- a/docs/for-ops/cli/x/index.html +++ b/docs/for-ops/cli/x/index.html @@ -14,13 +14,13 @@ - +
- + \ No newline at end of file diff --git a/docs/for-ops/console/apps/index.html b/docs/for-ops/console/apps/index.html index 96d68e2b2..447c147a8 100644 --- a/docs/for-ops/console/apps/index.html +++ b/docs/for-ops/console/apps/index.html @@ -14,13 +14,13 @@ - +

Platform - Apps

The apps section lists all apps available.

Activating apps​

When Otomi is installed, only the core applications are activated. To active more apps, hoover over the app you would like to activate and click on the activation button. All apps are configured with default configuration. To change the configuration, click on the configuration button and then click on VALUES.

info

Note: Some apps have dependencies with other apps. The dependencies can be found here. Dependencies are handled automatically.

App configuration​

By hoovering over the apps, a configuration item will appear. The app configuration section will show (if applicable) the following tabs:

Info​

Here you will find more information about the app and how the app is integrated into Otomi.

Shortcuts​

Create shortcuts to open the app at a target path. Created shortcuts will also become visable in the Shortcuts section

Values​

Here you will see the Otomi default values for the app that can be changed directly in Otomi Console. You can change the defaults to customize the configuration of the app.

Raw values​

In the Raw values, all values of the app chart that are not part of the Otomi values schema can be specified.

- + \ No newline at end of file diff --git a/docs/for-ops/console/backups/index.html b/docs/for-ops/console/backups/index.html index 317c5312a..adc393c97 100644 --- a/docs/for-ops/console/backups/index.html +++ b/docs/for-ops/console/backups/index.html @@ -14,13 +14,13 @@ - +

Platform - Backups

info

To enable this feature, first make sure Velero is activated.

When Velero is activated on the platform level, platform admins can create backups of Persistent Volumes (PVs) in Team namespaces using Otomi Console. When creating backups using Otomi Console, a Velero schedule resource is created that will create the backup at a specified time, defined by a Cron expression.

All known Backups on the platform are listed here. Builds can be sorted based on:

PropertyDescription
NameThe name of the backup
ScheduleWhen the backup is scheduled to run
TeamThe name of the Team responsible for the backup

Create a backup​

note

Backups of Team PVs can only be created by platform administrators

  1. Select the Team name in the top bar to set the context to the namespace that contains the PV to backup

  2. Enter a name for the backup

  3. Add the schedule of the backup. The schedule is a cron-type expression to schedule the backup. Defaults to once a day at 00:00. Create your cron-type expression here.

  4. (optional) Select Snapshot Volumes to snapshot volumes. This only applies to Persistent Volumes in Azure, GCE, and AWS.

  5. Add a label selector. Make sure your workload has the correct labels.

  6. (optional) Change the default TTL (expiration of the backup). Defaults to 7 days.

  7. Click Submit

- + \ No newline at end of file diff --git a/docs/for-ops/console/builds/index.html b/docs/for-ops/console/builds/index.html index e94a671d7..9f0bd52b3 100644 --- a/docs/for-ops/console/builds/index.html +++ b/docs/for-ops/console/builds/index.html @@ -14,13 +14,13 @@ - +

Platform - Builds

info

To enable this feature, first make sure Harbor and Tekton are activated. To be able to push images to Harbor, Otomi needs to be configured with a DNS and trusted certificates (Lets encrypt with production certificates).

All known Builds on the platform are listed here. Builds can be sorted based on:

PropertyDescription
NameThe name of the build
TypeType of the build. Buildpacks or Docker
Webhook urlThe copy to clipboard webhook URL if a trigger is configured for the build
TektonLink to the `PipelineRun`` of the build in the Tekton dashboard
RepositoryThe copy to clipboard repository name of the image
TagThe tag of the image
StatusThe status of the Build. If the Build has failed. click on the Tekton link to see more details
TeamThe name of the Team responsible for the build

A platform admin can also create builds. Make sure to select the correct context (team-name) in the top bar. See here for more information about creating builds.

- + \ No newline at end of file diff --git a/docs/for-ops/console/clusters/index.html b/docs/for-ops/console/clusters/index.html index dfd50b2c9..eeb4e7361 100644 --- a/docs/for-ops/console/clusters/index.html +++ b/docs/for-ops/console/clusters/index.html @@ -14,13 +14,13 @@ - +

Platform - Clusters

All known Otomi clusters are listed here. Clusters can be sorted based on:

PropertyDescription
ProviderThe configured Otomi provider (AWS, Azure, Google or Custom)
NameThe name of the cluster
URLThe URL of the Otomi Console of the cluster

Kubernetes clusters running Otomi can be linked by adding additional clusters in the Platform Settings / Otomi. This enables to switch context between clusters by selecting Cluster in the top bar.

- + \ No newline at end of file diff --git a/docs/for-ops/console/dashboard/index.html b/docs/for-ops/console/dashboard/index.html index 2e3800509..f64148987 100644 --- a/docs/for-ops/console/dashboard/index.html +++ b/docs/for-ops/console/dashboard/index.html @@ -14,13 +14,13 @@ - +

Platform Dashboard

The platform dashboard gives a global overview of information most relevant to the team. In the top bar, select the View: platform.

Prerequisites​

The Platform dashboard uses the Platform Grafana and prometheus to get it's information from. Make sure both are enabled.

Dashboard elements​

The dashboard has 3 elements

Team dashboard

Inventory​

The inventory shows the Otomi resources within the team. Click on an inventory item to go directly to the full list.

Cluster Resource Utilization​

The Cluster Resource Utilization shows:

  • CPU Utilization: The % used CPU of the total amount of CPU available in the cluster
  • Memory Utilization: The % used memory of the total amount of memory available in the cluster

Cluster Resource Request Commitments​

The Cluster Capacity shows:

  • CPU Request Commitment: The % configured requested CPU of the total amount of CPU available in the cluster
  • Memory Request Commitment: The % configured requested memory of the total amount of memory available in the cluster
- + \ No newline at end of file diff --git a/docs/for-ops/console/deploy-changes/index.html b/docs/for-ops/console/deploy-changes/index.html index 7e846a980..c10f1f9a7 100644 --- a/docs/for-ops/console/deploy-changes/index.html +++ b/docs/for-ops/console/deploy-changes/index.html @@ -14,13 +14,13 @@ - +

Deploy changes

When a change has been made, by pressing Submit, the Deploy Changes button will light up to deploy the changes you have made in the console. This will create a commit of the changes to the values repository in Gitea and trigger the Drone pipeline run.

- + \ No newline at end of file diff --git a/docs/for-ops/console/overview/index.html b/docs/for-ops/console/overview/index.html index 942cbc974..1aa1d3c17 100644 --- a/docs/for-ops/console/overview/index.html +++ b/docs/for-ops/console/overview/index.html @@ -14,13 +14,13 @@ - +

Overview

Otomi Console​

Otomi Console is the web UI of Otomi and offers access to all integrated apps and self-service tasks.

Otomi Console has a topbar showing a cluster and team selector, the logged-in user and a dark/light-mode. The team selector allows to switch to your desired context. Otomi Console also has a menu on the left. This menu shows the sections "Platform", "Team $name" and "Cluster".

Platform section​

The Platform section in the left menu provides access to:

  • Dashboard
  • Apps: All active and inactive apps. Activate apps by dragging them to the active apps section
  • Shortcuts: A list off all shortcuts created on this platform
  • Clusters: A list of all known Kubernetes clusters running Otomi
  • Policies: A list of all available security policies and their configuration for this platform
  • Teams: A list of all Teams using this platform
  • Builds: A list of all builds created on this platform
  • Secrets: A list of all secrets created on this platform
  • Workloads: A list of all workloads running on this platform
  • Services: A list of all services running on this platform
  • Settings: Specific configuration of the platform

Team section​

The Team $name section gives access to:

  • Apps: All the apps available to the team on this platform
  • Shortcuts: All shortcuts available to the team on this platform
  • Builds: A list of all builds created by the team
  • Secrets: A list of all secrets created by the team
  • Workloads: A list of all team workloads
  • Services: A list of all team services
  • Settings: Specific team configuration options

Cluster section​

The Cluster section shows:

  • Cluster information such as name, cloud, region, k8s version, otomi version, etc
  • A "Download KUBECFG" link to download a KUBECONFIG file that gives access to the namespace of the team selected. Admins can download one with cluster-admin permissions (giving access to all namespaces) by setting the team selector to '-'. You can use it like export KUBECONFIG=$file_location or by merging it with another KUBECONFIG file like .kube/config.
  • When Otomi uses an automatic generated CA or Let's Encrypt staging certificates, a "Download CA" link is provided.

Please visit the official Kubernetes documentation about managing kube contexts.

- + \ No newline at end of file diff --git a/docs/for-ops/console/policies/index.html b/docs/for-ops/console/policies/index.html index e372ae9d1..ebd3b52cd 100644 --- a/docs/for-ops/console/policies/index.html +++ b/docs/for-ops/console/policies/index.html @@ -14,13 +14,13 @@ - +

Platform - Policies

info

To enable this feature, first make sure OPA/Gatekeeper is activated.

This section allows to turn Open Policy Agent (OPA) / Gatekeeper policies on or off, and also set default parameters to be used by the policies.

SettingDescription
banned-image-tagsAdd any image tags for containers that are not allowed in your cluster.
container-limitsSet global compute limits for your containers.
psp-allowed-reposAdd globally allowed repositories for version control.
psp-host-filesystemSet policies for the host filesystem of all Kubernetes cluster nodes.
psp-allowed-usersDefault user (UID) settings to force containers to run with. It is recommended to at least set 'runAsUser' to 'MustRunAsNonRoot' to disallow root.
psp-host-securityWhether a pod is allowed to access the host PID namespace/host IPC, or if a pod defines host aliases.
psp-host-networking-portsWhether a pod can access ports on the host.
psp-privilegedWhether privileged containers can escalate to root privileges on the node.
psp-capabilitiesWhether to allow containers with sufficient capabilities granted to obtain escalated access.
psp-forbidden-sysctlsDetermine what system controls are allowed or not.
psp-apparmorPrevents an application from accessing files it should not access.
psp-seccompReduces the chance that a kernel vulnerability will be successfully exploited.
psp-selinuxSecurity-enhanced Linux.

Please see the OPA Gatekeeper policy library as it is the source for the policies here. We made a selection of usable policies for Otomi and adapted them to be used by Conftest as well for static analysis of manifests generated by Otomi.

- + \ No newline at end of file diff --git a/docs/for-ops/console/projects/index.html b/docs/for-ops/console/projects/index.html index 9c2db3f33..d24a0c3da 100644 --- a/docs/for-ops/console/projects/index.html +++ b/docs/for-ops/console/projects/index.html @@ -14,13 +14,13 @@ - +

Projects

A Project in Otomi is a collection of a Build, a Workload and a Service in ONE form. When a user creates a project, the name of the project will be used for all created tasks (build, workload, service).

All known Builds on the platform are listed here. Builds can be sorted based on:

PropertyDescription
NameThe name of the project
TeamThe name of the Team responsible for the project

Follow the instructions here to create a project.

- + \ No newline at end of file diff --git a/docs/for-ops/console/secrets/index.html b/docs/for-ops/console/secrets/index.html index b5231d2fa..a3f7d8977 100644 --- a/docs/for-ops/console/secrets/index.html +++ b/docs/for-ops/console/secrets/index.html @@ -14,13 +14,13 @@ - +

Platform - Secrets

info

To enable this feature, first make sure Hashicorp Vault is activated.

All known Builds on the platform are listed here. Builds can be sorted based on:

PropertyDescription
NameThe name of the secret
TypeThe secret type (generic, docker-registry, TLS)
TeamThe name of the Team responsible for the secret

A platform admin can NOT create secrets and does NOT have access to the team's secrets in Vault. In case an administrator needs access to team secrets, retrieve the vault vault-unseal-keys and sign in with the token method. See here for detailed instructions.

- + \ No newline at end of file diff --git a/docs/for-ops/console/services/index.html b/docs/for-ops/console/services/index.html index eda2145a1..20be9ed6c 100644 --- a/docs/for-ops/console/services/index.html +++ b/docs/for-ops/console/services/index.html @@ -14,13 +14,13 @@ - +

Platform - Services

All known Services on the platform are listed here. Services can be sorted based on:

PropertyDescription
Service NameThe name of the service
Ingress classThe ingress class configured. This is the ingress controller that exposes the service
URLThe URL of the service if the service is configured for external exposure
StatusThe status of the service
TeamThe team that owns the service

Follow the instructions here to create a service.

- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/alerts/index.html b/docs/for-ops/console/settings/alerts/index.html index 34b6c7311..fb25a3187 100644 --- a/docs/for-ops/console/settings/alerts/index.html +++ b/docs/for-ops/console/settings/alerts/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Alerts​

note

Alerts settings will only be active when Alertmanager is active.

The alerts settings section offers configuration options to define alerting endpoints for alert manager and deployment feedback. The list of providers selected in Notification receivers should reflect their configuration. I.e. when receiver "slack" is selected, the slack configuration needs to be defined. Teams can also configure additional endpoints for the alerts spawning from their team namespace.

SettingDescription
Repeat intervalIndicates waiting time before sending a notification again after it was sent successfully for an alert. (Usually ~3h or more).
Group intervalHow long to wait before sending a notification about new alerts that are added to a group of alerts for which an initial notification has already been sent. (Usually ~5m or more.)
SlackSlack webhook url and channels for critical and non-critical alerts.
MSteamsMicrosoft Teams webhook urls for critical (high prio) and non-critical alerts (low prio).
EmailEmail address(es) for critical and non-critical alerts.
Notification receiversSelect default notification channel(s) for receiving alerts.
- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/azure/index.html b/docs/for-ops/console/settings/azure/index.html index bff005048..fbd771dcd 100644 --- a/docs/for-ops/console/settings/azure/index.html +++ b/docs/for-ops/console/settings/azure/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Azure​

note

Azure settings will only be active when cluster.provider=azure.

The Azure settings section offers specific configuration options when running Otomi on a Kubernetes cluster in Azure. Note that this section will only be available when running on Azure (cloud=azure).

SettingDescription
AppgwSelect if Azure Application Gateway is used as an external Load Balancer.
Azure MonitorTurn on Azure monitor to use Azure metrics in Grafana dashboards.
Storage TypesSpecify the Azure disk types used for storage classes in Otomi.

IMPORTANT NOTES:

Using an Azure Application Gateway is optional. In case an application gateway is used with a WAF, make sure that its on detection mode and not prevention, as this might deny traffic to your cluster, which can have consequences on the availability of services. For example Grafana relies heavily on queries inside the api request that might trigger OWASP rules.

- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/backup/index.html b/docs/for-ops/console/settings/backup/index.html index 4094dd28d..10b312a30 100644 --- a/docs/for-ops/console/settings/backup/index.html +++ b/docs/for-ops/console/settings/backup/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Backup​

The Backup section provides the option to enable automatic backups of Persisten Volumes of platform K8s applications. The Backup option will only be accessible if the Velero app is enabled.

If backup is enabled for a specif app, this will create a Velero backup schedule to automatically backup the PVC's of the app.

SettingDescription
EnabledSelect to enable the backup of Otomi platform services
TTL After FinishedExpiration of the backup.
ScheduleCron-type expression to schedule the backup. Defaults to once a day at 00:00.
- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/cluster/index.html b/docs/for-ops/console/settings/cluster/index.html index 0e013c056..d7f749269 100644 --- a/docs/for-ops/console/settings/cluster/index.html +++ b/docs/for-ops/console/settings/cluster/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Cluster​

The Cluster section provides information about the Kubernetes cluster running Otomi.

Cluster​

SettingDescriptionConfigurable
NameShort name that will be used in construction of cluster domain and messaging.Yes
Domain SuffixDomain suffix for the cluster.Yes
API NameName of cluster. On AWS this must match the exact EKS cluster name.No
API ServerAdd the full url of the kubernetes API server. This is used to generate the KUBECONFIG for local API access.Yes
OwnerA cluster owner. Used in alerts/reports to distinguish between resources for different customers.Yes
AWS RegionAn AWS region. Used by charts such as cluster-autoscaler and aws-certs job. Example: eu-central-1No

Provider​

The provider used for this cluster

Kubernetes version​

The version of the Kubernetes cluster running Otomi.

- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/co-monitoring/index.html b/docs/for-ops/console/settings/co-monitoring/index.html index dc301c281..8fba692fa 100644 --- a/docs/for-ops/console/settings/co-monitoring/index.html +++ b/docs/for-ops/console/settings/co-monitoring/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Co-Monitoring​

note

Co-Monitoring settings will only be active when Alertmanager is active.

This section is similar to the Alerts section, but with a different intent: the configuration here is meant to target 3rd party alerting endpoints. Those will become active when the Remote monitoring option (in Settings/Otomi) is turned on. When used, the "Alerts" section should only contain endpoints for the 3rd party. Of course teams can still configure their own alert endpoints.

- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/dns/index.html b/docs/for-ops/console/settings/dns/index.html index ddcd5bf16..3b9df6589 100644 --- a/docs/for-ops/console/settings/dns/index.html +++ b/docs/for-ops/console/settings/dns/index.html @@ -14,13 +14,13 @@ - +

Platform settings

DNS​

note

DNS settings will only be active when otomi.hasExternalDNS=true flag is set during installation. This can also be set after installation in Settings/Otomi.

Zones​

Add additional DNS zones Extra that the cluster can administer. Team services can use these zones to publish their URL's on.

Domain filters​

Limit possible target Zones by suffix.

Zone ID filters​

Limit the possible target zones by zone id.

Provider​

The DNS provider used to manage the domain(s).

The followingDNS providers are supported in Otomi:

  • AWS
  • Azure (Public zones)
  • Azure Private DNS
  • CloudFlare
  • Digital Ocean
  • Google
  • Other

When Other is selected, the required values can be added to support any other DNS provider (supported by External DNS).

- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/ingress/index.html b/docs/for-ops/console/settings/ingress/index.html index 060d20cdd..00da3d34e 100644 --- a/docs/for-ops/console/settings/ingress/index.html +++ b/docs/for-ops/console/settings/ingress/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Ingress​

note

Using multiple ingress classes / Ingress controllers is only supported if cluster.provider=azure.

By default (after installing Otomi), one ingress controller (ingress-nginx-platform) is deployed and is used to publicly expose both platform and user created services. In the settings for ingress, an admin can:

  1. Configure the platform ingress class to be private (using a private load balancer)
  2. Add additional ingress classes to expose user created services

By changing the platform ingress class from public to private, all platform services (like Otomi Console, the Keycloak platform instance and all other platform end-points) will only be accessible from the private network.

By adding additional ingress classes, each class will get a dedicated ingress controller and a dedicated cloud load balancer. This allows grouping of services and exposing them to differend networks.

- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/key-management/index.html b/docs/for-ops/console/settings/key-management/index.html index 45fb78300..969aa7329 100644 --- a/docs/for-ops/console/settings/key-management/index.html +++ b/docs/for-ops/console/settings/key-management/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Key management​

The Key management settings section offers configuration options for the Key Management Service (KMS) information needed to seal and unseal secrets used by Otomi. Otomi needs at least one key. It needs one for encrypting/decrypting the otomi-values repo, and one for sealing/unsealing Vault storage.

IMPORTANT NOTES:

  • When omitting KMS credentials for SOPS, the secrets in the otomi-values repo will be stored in plain text
  • When omitting KMS credentials for Vault, on startup it will generate its own k8s secret for sealing/unsealing, so be careful not to remove it!

It is advised to provide credentials to an external stable KMS (such as from the cloud the cluster was deployed in), so that unseal keys can always be managed from one central location. The same credentials can be used for both SOPS and Vault.

- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/oidc/index.html b/docs/for-ops/console/settings/oidc/index.html index 357de01c8..1fc3f0370 100644 --- a/docs/for-ops/console/settings/oidc/index.html +++ b/docs/for-ops/console/settings/oidc/index.html @@ -14,13 +14,13 @@ - +

Platform settings

OIDC​

note

OIDC settings will only be active when the otomi.hasExternalIDP=true flag is set during installation. This can also be set after installation in Settings/Otomi.

The OIDC settings section offers configuration options to connect with an external Identity Provider (Bring Your Own IDP). This allows to map IDP group names to the following Otomi roles:

  • Otomi admins (adminGroupID)
  • Team admins (teamAdminGroupID)
- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/otomi/index.html b/docs/for-ops/console/settings/otomi/index.html index 19248f890..5ddc5585b 100644 --- a/docs/for-ops/console/settings/otomi/index.html +++ b/docs/for-ops/console/settings/otomi/index.html @@ -14,13 +14,13 @@ - +

Platform settings

Otomi​

The Otomi settings section offers configuration options for Otomi and feature flags that influence the way Otomi behaves.

SettingDescription
Admin passwordDefault admin password for all Otomi apps. The default admin password can not be changed.
Additional ClustersA list of additional clusters to select in the Otomi console.
Global pull secretsAdd you Dockerhub pull secret. Will be connected to each "default" service account in all Otomi app namespaces. Handy for authenticating with DockerHub to avoid rate limiting. Also useful when pulling all Otomi images from a private repo.
Cloud ingress controllerSet this to true when using a cloud specific ingress controller. By default the Nginx Ingress Controller is used.
External DNSSet this to true when an external DNS zone is available to manage DNS records. (Expects required dns: fields to be set.)
External IdPSet this to true when bringing your own external IDP such as Azure AD. (Expects required oidc: fields to be set.)
Remote monitoringWhen this is turned on alerts will also be sent to the endpoints configured in the "Co-monitoring" settings.
Multi-tenancyWhen turned on, team metrics and logs will be separated. Disabling this lets everybody be admin and see everything. Will still use team-* namespaces for segmentation and network isolation of services.
Node SelectorWhen a label/value pair is added, all Otomi platform workloads will be scheduled on the nodes with this label/value pair
Otomi VersionThe installed version of Otomi. Change to a new valid release to upgrade
- + \ No newline at end of file diff --git a/docs/for-ops/console/settings/smtp/index.html b/docs/for-ops/console/settings/smtp/index.html index cfbd9c1ba..503f47157 100644 --- a/docs/for-ops/console/settings/smtp/index.html +++ b/docs/for-ops/console/settings/smtp/index.html @@ -14,13 +14,13 @@ - +

Platform settings

SMTP​

note

SMTP settings will only be active when Alertmanager is active.

The alerts settings section offers configuration options to define for Mail server settings. A mail server needs to be configured in case email notifications are used.

- + \ No newline at end of file diff --git a/docs/for-ops/console/shell/index.html b/docs/for-ops/console/shell/index.html index 77fd6682b..121d1b3ef 100644 --- a/docs/for-ops/console/shell/index.html +++ b/docs/for-ops/console/shell/index.html @@ -14,13 +14,13 @@ - +

Shell

The Shell feature allows to start a web based shell in Otomi Console with Kube API access. When starting a shell, a dedicated shell instance will be started for the user. The shell includes the following tools:

info

When running the shell as a platform administrator, the shell will allow access to all cluster resources.

- + \ No newline at end of file diff --git a/docs/for-ops/console/shortcuts/index.html b/docs/for-ops/console/shortcuts/index.html index edb9166d8..f33cecb0f 100644 --- a/docs/for-ops/console/shortcuts/index.html +++ b/docs/for-ops/console/shortcuts/index.html @@ -14,13 +14,13 @@ - +

Platform - Shortcuts

The Shortcuts section shows all shortcuts created and available on the platform for users with the otomi-admin role.

Otomi provides the following default shortcuts to be used:

AppLinkComments
GrafanaNGINX: NGINX ingress controller metricsOnly works if Grafana is enabled
KeycloakAccount: Edit your account settings
LokiIngress logs: all logs generated in the "ingress" namespaceOnly works if loki is enabled
LokiOWASP violations: ingress traffic triggering OWASP rulesOnly works if both Loki and OWASP filtering are enabled
LokiGatekeeper violations: Kube API violations logged by OPA gatekepeerOnly works if both Loki and Gatekeeper are enabled

When a shortcut is grayed-out, the app used for the shortcut is not enabled.

- + \ No newline at end of file diff --git a/docs/for-ops/console/teams/index.html b/docs/for-ops/console/teams/index.html index 92680f3ab..462b45e08 100644 --- a/docs/for-ops/console/teams/index.html +++ b/docs/for-ops/console/teams/index.html @@ -14,13 +14,13 @@ - +

Platform - Teams

  • Teams are tenants on the platform to support Development/DevOps teams, projects or even DTAP
  • A team will get access to Otomi Console, providing access to all the shared apps available on the platform
  • Teams can choose to receive alerts in Microsoft Teams, Slack or email and each team will get access to a project in Harbor and a space in Vault to manage secrets
  • Teams can be allowed self-service features like configure ingress, configure a notification receiver for alerts, change the OIDC group mappings and download the KubeConfig.

Team Admin​

By default, Otomi creates a team called Team Admin. Admins can use this team to expose any service in the team-admin namespace, but also in other namespaces.

see Team Services for more info about how to create Services in Otomi and how to configure ingress. The only difference here is that when creating Services in Team Admin, the admin can also select the namespace of the service.

Another difference between the Team Admin and user created Teams is that Team Admin does not have apps and it is not possible to configure any settings for the team-admin namespace.

Creating new Teams​

  1. Login with a user who is a member of the otomi-admin or team-admin role

  2. Provide a name for the team (lowercase). The teamname can not be changed afterwards! Creating a team will result in the creation of namespace team-$NAME. The name of a team can be max 12 characters.

  3. Optional: Provide a OIDC group name/id granting for granting access to team. Only members of the group will get access to the team

  4. Optional (only when Alert Manager is enabled for the team): In order to receive alerts, please choose an alerting endpoint:

OptionDescription
SlackNeeds a slack webhook url that will give alerts for warnings and criticals
Microsoft TeamsNeeds two alerting endpoints, for both warnings as well as criticals
EmailYou may provide a list of email addresses for both 'Non Critical' and 'Critical'
If none selectedGlobal (admin) alerting endpoint configuration will be used
  1. Optional (Only if Opencost is enabled): Configure billing alert quota

Billing alert quota can be configured to receive an alert when a team hits a quota. Quota are not enforced, meaning a team can still consume resources even when a quota has been reached.

  1. Optional: Add Resource Quotas

When required, add resource quota for the team. The resource quota should adhere to the "spec.hard" format as described here.

Note

There is no validation as there is no schema published. Add/change resource quota at your own risk.

  1. Optional: Configure Azure Monitor
note

Configuring Azure Monitor settings will only be shown when cluster.provider=azure).

Azure Monitor is the platform service that provides a single source for monitoring Azure resources.

OptionDescription
No Azure monitoring-
Azure monitoring with global settingsTakes on the global settings
Azure monitoring with custom settingsOverrides any global settings
  1. Managed Monitoring

Activate a (platform) managed Prometheus, Grafana and/or Alertmanager instance.

  1. Turn Network Policy On/Off for the team
OptionDescription
Network policiesWhen enabled team services will be bound by (ingress) network policies
Egress controlWhen enabled team service egress traffic will be limited to pre-defined endpoints only
  1. Add Team self service flags

A user with the otomi-admin and team-admin role can delegate permissions to modify certain configuration parameters to the team.

SectionOptionDescription
ServiceIngressSelect to grant the team the permission to configure exposure for Services
ServiceNetwork policySelect to grant the team the permission to configure network polices
TeamAlertsSelect to grant the team the permission to configure Alerts for the team
TeamBilling alert quotasSelect to grant the team the permission to configure Billing alerts for the team
TeamOidcSelect to grant the team the permission to configure OIDC for the team
TeamResource quotaSelect to grant the team the permission to configure Resource Quota for the team
TeamDownload kube configSelect to grant the team the permission to download the KubeConfig to get Kube API access to the teams namespace
TeamDownload docker configSelect to grant the team the permission to download the Dockerconfig for the teams project in Harbor
TeamNetwork PolicySelect to grant the team the permission to turn on/off network policies
- + \ No newline at end of file diff --git a/docs/for-ops/console/workloads/index.html b/docs/for-ops/console/workloads/index.html index 21cb41703..21e8a9713 100644 --- a/docs/for-ops/console/workloads/index.html +++ b/docs/for-ops/console/workloads/index.html @@ -14,13 +14,13 @@ - +

Platform - Workloads

info

To enable this feature, first make sure Argo CD is activated.

All known Workloads on the platform are listed here. Workloads can be sorted based on:

PropertyDescription
NameThe name of the workload
ArgocdLink to the Argo CD application in the Argo CD UI
Image update strategyThe configured update strategy for the workload
StatusThe status of the workload. Click on the Argo CD application link to see more status details
Team NameThe name of the Team responsible for the workload

A platform admin can also create Workloads. Make sure to select the correct context (team-name) in the top bar. See here for more information about creating builds.

- + \ No newline at end of file diff --git a/docs/for-ops/how-to/backups/index.html b/docs/for-ops/how-to/backups/index.html index 9fe34fa1f..403edaa1f 100644 --- a/docs/for-ops/how-to/backups/index.html +++ b/docs/for-ops/how-to/backups/index.html @@ -14,13 +14,13 @@ - +

Create/Restore backups

When Velero is activated on the platform level, platform admins can create backups of Persistent Volumes (PVs) in Team namespaces using Otomi Console. When creating backups using Otomi Console, a Velero schedule resource is created that will create the backup at a specified time, defined by a Cron expression.

In this how-to, we'll create a backup of a PV using Otomi and then restore it using the velero CLI integrated into the Otomi Shell.

Prerequisites​

To perform this how-to, first make sure Velero is enabled. Velero requires object storage to be be configured. By default Velero uses the local Minio provided by Otomi. In this how-to we'll use Minio.

When Otomi installs Velero, the Velero plug-in for Azure, AWS and Google are configured by default. Velero also has support for backing up and restoring Kubernetes volumes using Restic. Note that Restic is not enabled by default.

For this how-to we'll use the PV of a Team's private Prometheus instance, so make sure Prometheus is also enabled.

Create a backup schedule using Otomi​

  1. Select the Team name in the top bar to set the context to the namespace that contains the PV to backup. In this how-to we'll use the team demo.
  2. In Otomi Console, click on Backup in the left menu under Platform and click on Create.
  3. Enter a name for the backup. In this how-to we'll use the name prom.
  4. Add the schedule of the backup. The schedule is a cron-type expression to schedule the backup. Defaults to once a day at 00:00. Create your cron-type expression here.
  5. Using snapshots only applies to Persistent Volumes in Azure, GCE, and AWS.
  6. In this how-to, we'll create a backup of the private Prometheus PV in the demo team by using a labelSelector
note

If the labelSelector is not used, the backup schedule will backup all PVs of the team.

  • In Otomi Console, click on Shell in the bottom of the left menu.
  • Run the following cmd in the shell:
kubectl get statefulset prometheus-demo-po-prometheus -n team-demo --show-labels
\NAME                            READY   AGE   LABELS
prometheus-demo-po-prometheus   1/1     77m   app.kubernetes.io/instance=prometheus-demo,app.kubernetes.io/managed-by=Helm,app.kubernetes.io/part-of=demo-po,app.kubernetes.io/version=46.4.1,app=demo-po-prometheus,chart=kube-prometheus-stack-46.4.1,heritage=Helm,operator.prometheus.io/mode=server,operator.prometheus.io/name=demo-po-prometheus,operator.prometheus.io/shard=0,prometheus=team-demo,release=prometheus-demo
  • click on Add Item and fill in the following:
name: prometheus
value: team-demo
  1. Use the default TTL (expiration of the backup). Defaults to 7 days.
  2. Click Submit

Check if the schedule is created​

  1. In Otomi Console, click on Shell in the bottom of the left menu
  2. Run the following cmd in the shell:
velero get schedules
NAME                    STATUS    CREATED                         SCHEDULE     BACKUP TTL   LAST BACKUP   SELECTOR   PAUSED
team-demo-backup-prom   Enabled   2023-09-24 11:50:59 +0000 UTC   55 * * * *   168h0m0s     n/a           <none>     false

Check if the backup is created​

  • Run the following cmd in the shell:
velero get backups
NAME                                   STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
team-demo-backup-prom-20230924115514   Completed   0        0          2023-09-24 11:55:14 +0000 UTC   6d        otomi              prometheus=team-demo

You can see the status of the backup is Completed. The backup is now stored in the local Minio.

Restore the backup​

Now the backup is created, we can restore the backup.

Follow this procedure to restore a backup:

  • Scale down the replicas of the deployment or statefulset that uses the PV

  • Delete the PVC. You can find the name of the PVC in the deployment spec.template.spec.volumes

  • Run the following cmd in the shell:

velero restore create --from-backup team-demo-backup-prom-20230924115514
Restore request "team-demo-backup-prom-20230924115514-20230924133133" submitted successfully.
Run `velero restore describe team-demo-backup-prom-20230924115514-20230924133133` or `velero restore logs team-demo-backup-prom-20230924115514-20230924133133` for more details.
  • Scale up the replicas of the deployment or statefulset to use the restored PV

Manually create backups​

Otomi only provides a self-service option for administrators to schedule backups of persistent volumes within team namespaces. The shell in Otomi includes the Velero CLI, so if you're confortable with Velero you can also create you're own custom backups. Check the docs on https://velero.io/ for more information.

This is an example of creating a custom backup:

  • Create a full backup (to backup all resources, including PVs)
velero backup create my-custom-backup-01 --include-namespaces team-demo
  • Create a backup of specific resources:
velero backup create my-custom-backup-02 --include-namespaces team-demo --include-resources secret,deployment
  • Verify the backup:
velero describe backup my-custom-backup-01 --details
  • Restore a backup:
velero restore create --from-backup my-custom-backup-01
- + \ No newline at end of file diff --git a/docs/for-ops/how-to/core-only/index.html b/docs/for-ops/how-to/core-only/index.html index 7ec8f94c7..8713dc067 100644 --- a/docs/for-ops/how-to/core-only/index.html +++ b/docs/for-ops/how-to/core-only/index.html @@ -14,13 +14,13 @@ - +

Use Otomi Core only

Otomi by default installs Gitea, Drone, Otomi API and Otomi Console. Otomi Console is the self-service UI and uses Otomi API to generate validated configuration code. This configuration code is then committed to Gitea (in the values repository), which will trigger teh pre-configured Drone pipeline to apply the changes.

In some cases you might not want to use Otomi Console, Otomi API and Drone, but instead install and manage configuration of the platform using a custom pipeline. Possible use-cases for this scenario are:

  • Pushing configuration changes to multiple clusters at the same time (edge use-case)
  • Not allowing configuration changes be made by developers
  • Only using the open source otomi-core project

Example​

The example Otomi chart values below shows how to install Otomi with

  • A team with 2 workloads and 2 services
cluster:
  name: ${clusterName}
  provider: ${clusterProvider}
otomi:
  adminPassword: ${password}
apps:
  argocd:
    enabled: true
teamConfig:
  demo:
    password: ${somePassword}
    id: myapp
    networkPolicy:
      egressPublic: true
      ingressPrivate: true
    services:
      - name: front-end
        ingressClassName: platform
        networkPolicy:
            ingressPrivate:
                mode: DenyAll
        ownHost: true
        port: 8080
        type: public
        headers:
          response:
            set:
              - name: Cache-Control
                value: no-store
              - name: Pragma
                value: no-cache
      - name: api
        networkPolicy:
            ingressPrivate:
                mode: AllowOnly
                allow:
                  team: myapp
                  service: front-end
        port: 8081
    workloads:
      - name: front-end
        path: ksvc
        revision: v1.0.1
        selectedChart: ksvc
        url: https://github.com/redkubes/otomi-charts.git
      - name: api
        path: deployment
        revision: v1.0.1
        selectedChart: deployment
        url: https://github.com/redkubes/otomi-charts.git
files:
  env/teams/workloads/demo/front-end.yaml: |
    values: |
        fullnameOverride: front-end
        image:
            repository: harbor.${domainSuffix}/team-demo/front-end
            tag: latest
        containerPorts:
            - name: http1
            containerPort: 8080
            protocol: TCP
        resources:
            requests:
                cpu: 200m
                memory: 32Mi
        autoscaling:
            minReplicas: 0
            maxReplicas: 10    
  env/teams/workloads/demo/api.yaml: |
    values: |
      image:
        image:
            repository: harbor.${domainSuffix}/team-demo/api
            tag: latest
        containerPorts:
            - name: http1
            containerPort: 8080
            protocol: TCP
        resources:
            requests:
                cpu: 200m
                memory: 32Mi
        autoscaling:
            minReplicas: 1
            maxReplicas: 10

You can now make changes in this configuration and apply them directly to the cluster:

  1. Install Otomi using your custom values:
helm install -f values.yaml otomi otomi/otomi

After Otomi has been installed with these values, Otomi will install and configure:

  • All required ingress resources
  • Istio (including the virtual services for public exposed services with HTTP response headers)
  • Network policies
  • Argo CD and Argo CD application sets to automatically deploy the front-end and api workloads
  1. Change the values

You can extend the values with all Otomi supported configuration.

  1. Uninstall the Otomi release:
helm uninstall otomi --no-hooks
  1. Re-install the chart with the adjusted values:
helm install -f values.yaml otomi otomi/otomi
- + \ No newline at end of file diff --git a/docs/for-ops/how-to/dev-catalog/index.html b/docs/for-ops/how-to/dev-catalog/index.html index ccdc97f32..5c42a3e2e 100644 --- a/docs/for-ops/how-to/dev-catalog/index.html +++ b/docs/for-ops/how-to/dev-catalog/index.html @@ -14,13 +14,13 @@ - +

Managing the Catalog

Otomi offers a Catalog to Teams on the platform to offer them golden path templates (Helm charts). This is how it works:

  • Add a Helm chart to the otomi/charts repo in the local Gitea
  • Configure which Teams can use the chart
  • Teams can create Workloads from the Catalog

After Otomi is installed, the catalog (the otomi/charts repo) will contain a set of quick start Helm charts. Tbe The Otomi provided Helm charts are not mandetory to use and can be removed or modified to your own liking. They are only provided to make it easier to get started.

Otomi quick start Helm charts​

The Catalog contains a set of Helm charts that can be used as quick starts. The following quick starts are available:

k8s-deployment​

The otomi-quickstart-k8s-deployment Helm chart can be used to create a Kubernetes Deployment (to deploy a single image), a Service and a ServiceAccount. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap can be created.

k8s-deployment-otel​

The otomi-quickstart-k8s-deployment-otel Helm chart can be used to create a Kubernetes Deployment (to deploy a single image), a Service, a ServiceAccount, an OpenTelemetryCollector and an Instrumentation. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap can be created.

k8s-deployments-canary​

The otomi-quickstart-k8s-deployments-canary Helm chart can be used to create 2 Kubernetes Deployments (to deploy 2 versions of an image), a Service and a ServiceAccount. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap (for each version) can be created.

knative-service​

The otomi-quickstart-knative-service Helm chart can be used to create a Knative Service (to deploy a single image), a Service and a ServiceAccount. Optionally a Prometheus ServiceMonitor can be created.

Otomi quick start for creating a PostgreSQL cluster​

The otomi-quickstart-postgresql Helm chart can be used to create a cloudnativepg PostgreSQL Cluster. Optionally a Prometheus PodMonitor and a Configmap (for adding a postgresql dashboard to Grafana) can be created.

Otomi quick start for creating a Redis master-replica cluster​

The otomi-quickstart-redis Helm chart can be used to create a Redis master-replica cluster.

Customize the catalog​

The Otomi provided charts are not mandetory to use and can be removed or modified to your own liking. They are only provided to make it easier to get started. To manage the catalog, just pull the otomi/charts repo, add the Helm charts you would like to make available and push changes. A newly added chart will immediately become available in the catalog for Teams to use.

Configure chart access​

For charts to become available for Teams to use, Teams need to be given access to use a chart. The catalog supports the following access options:

Everybody​

If a chart can be used by all teams, including the team-admin Team, add the following to the rbac.yaml in the root of the otomi/charts repository:

rbac:
  chart-name: null

Specific teams​

If a chart is only allowed to be used by one or more specific teams, add the following to the rbac.yaml:

rbac:
  chart-name:
    - team-demo
    - team-hello

To allow a chart to be used by the team-admin only, add the following to the rbac.yaml:

rbac:
  chart-name:
    - team-admin
- + \ No newline at end of file diff --git a/docs/for-ops/how-to/ingress-classes/index.html b/docs/for-ops/how-to/ingress-classes/index.html index 563443289..ad52ca694 100644 --- a/docs/for-ops/how-to/ingress-classes/index.html +++ b/docs/for-ops/how-to/ingress-classes/index.html @@ -14,13 +14,13 @@ - +

Manage Ingress Controllers

When Otomi is installed, exposure (ingress) for all services (included exposure for platform services) is handeled by the default platform ingress class using a public (cloud) load balancer. Otomi offers the option to use multiple ingress classes. Each class get a dedicated ingress controller. In case of security requirements, where platform services are not allowed to be exposed publicly, the default platform class can be configured to use a private load balancer instead of a public one. Additional (public) ingress classes can be created to expose team (application) services.

prerequisites​

  • Access to the internal subnet (using a VPN or a Jumphost)
  • cluster.provider=azure

Steps​

Steps to change to use a private load balancer for exposing platform services:

If there are no team services created that use the default platform class, then you can skip step 2.

  1. Create an additional public ingress class
  • Go to Ingress Classes under Settings in the web UI
  • Under additional classes click on add item
  • Provide a name for the additional ingress class (for example teams)
  • Use the public load balancer type
  • (optional) If you would like to create a new load balancer in another resource group, fill in the name of that resource group
  • (optional) If you would like to use a static (public) IP for the load balancer, then fill in the IP address. More information about using static IP addresses can be found here
  • Click submit and then deploy changes
  1. Move all existing team services to use the new ingress class:
  • Go to services, click on the service you would like to move to the new ingress class
  • Under Exposure Ingress, fill in the name of the new ingress class in the ingress class name field.
  • Click submit and then deploy changes
  1. Change the platform class from public to private:
  • Go to Ingress Classes under Settings in the web UI
  • Under Platform class, select private
  • (optional) If you would like to use a static IP for the load balancer, then fill in the IP address

By default the internal load balancer is is created in the node resource group and connected to the same virtual network as the AKS cluster. If you would like to use a different resource group and subnet, fill in the Resource Group name and the subnet.

  • Click submit and then deploy changes

When the platform ingress class has been configured to use an internal load balancer, Otomi will add the following annotations to the K8s load balancer service of the platform ingress controller:

service.beta.kubernetes.io/azure-load-balancer-resource-group: {{ . }}
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "{{ . }}"
- + \ No newline at end of file diff --git a/docs/for-ops/how-to/overview/index.html b/docs/for-ops/how-to/overview/index.html index 647f39db1..0689e1928 100644 --- a/docs/for-ops/how-to/overview/index.html +++ b/docs/for-ops/how-to/overview/index.html @@ -14,13 +14,13 @@ - +
- + \ No newline at end of file diff --git a/docs/for-ops/how-to/switch-to-dns/index.html b/docs/for-ops/how-to/switch-to-dns/index.html index 65891eb4a..32ab87dfe 100644 --- a/docs/for-ops/how-to/switch-to-dns/index.html +++ b/docs/for-ops/how-to/switch-to-dns/index.html @@ -14,13 +14,13 @@ - +

Switch to use DNS

When Otomi is installed with minimal values, a custom CA is generated and Otomi uses nip.io for host names. It is possible to switch from nip.io to using a DNS zone after installing Otomi initially without DNS. To switch from nip.io to a DNS zone, follow the instructions as described below.

Step 1: Enable external DNS flag​

  • Sing in to Otomi Console with user otomi-admin
  • In the left menu, click on Setting under Platform
  • Click on Otomi
  • Enable the External DNS option
  • Click on Submit

Step 2: Provide DNS values​

  • Go back to the Settings and click DNS
  • Provide the Domain filter and optionally the Zone id filters
  • Select your Provider
  • Provide the required values
  • Click on Submit

Step 3: Set cluster domain suffix​

  • Go back to the Settings and click Cluster
  • Provide the cluster Domain Suffix
  • Click on Submit

Step 4 (optional): Use Let's Encrypt​

Let's Encrypt requires a DNS zone. So if you would like to start using Let's Encrypt as a CA, now you can.

  • Click on Apps under platform
  • Click on the cert-manager app
  • Click on the values tab
  • Fill in an email address with a valid domain name (required!)
  • Under Issuer, click on Lets Encrypt
  • Select Production
  • Click on Submit

Step 5: Deploy Changes​

In the left menu, click on Deploy Changes

Wait for the Drone runner to finish:

kubectl get pod -n drone-pipelines -w

Step 6: Adjust the webhook in Gitea​

Open Gitea and follow these steps:

First sign in to the Otomi Console using the new domain name: https://otomi.<your-domain-name>

  • Click on Apps under Platform
  • Click on the Gitea app
  • Sign in
  • Click on the otomi/values repository
  • Click Settings
  • Click Webhooks
  • Click on the existing webhook (https://drone.<ip-address>.nip.io/)
  • Change the domain name in the target URL to your new domain name
  • Click Update Webhook

Step 7: Restart and Authorize Drone​

After the webhook is adjusted, restart Drone:

kubectl delete pod -n drone -l app=drone

When the pods have restarted and are in a running state:

  • Click on Apps under Platform
  • Click on the Drone app
  • Click on Sign In on the 404 page
  • Click Continue
  • Click on Authorize Application
  • Complete the Drone registration
  • Click Submit

Now you still see the pipeline running of the DNS change is still running. You can manually cancel the pipeline by clicking on the pipeline and then click cancel in the top right.

You're ready to go!

- + \ No newline at end of file diff --git a/docs/for-ops/how-to/use-team-admin/index.html b/docs/for-ops/how-to/use-team-admin/index.html index 87c07a5b8..30f64be36 100644 --- a/docs/for-ops/how-to/use-team-admin/index.html +++ b/docs/for-ops/how-to/use-team-admin/index.html @@ -14,13 +14,13 @@ - +

Use team-admin

When Otomi is installed, by default a team called team-admin is created. The Admin Team is no regular team. This team for instance has no apps. Instead the admin needs to use the platform apps to see logs and metrics of workloads deployed in the team-admin namespace.

The Admin Team can be used by admins to:

  • Deploy workloads in any namespace
  • Configure ingress for any service in any namespace

This makes it possible for admin to add any kind of tool to the platform and use the Services in Otomi to expose the UI of the tool and configure SSO.

Create workloads in any namespace​

To create workloads in a namespace not managed by Otomi (namespaces not owned by teams created in Otomi), first create a namespace with label istio-injection: enabled:

kubectl create namespace my-namespace
kubectl label namespace my-namespace istio-injection=enabled

You can now create a workload to deploy Helm charts to this new namespace. In this example we'll use the deployment chart in the otomi-charts repo. In the left menu, under team-admin click Workloads and then click Create Workload.

  1. Enter a name for the workload
hello-deploy
  1. Enter the URL to the Git repo containing the Helm Chart or a Helm repository:
https://github.com/redkubes/otomi-charts.git
  1. Enter the path of the chart
deployment

  1. Enter the revision. In case of using a Git repo, this can be commit, tag, or branch. If omitted, will equal to HEAD. In case of using a Chart repository, this is a semver tag for the Chart's version

  2. Enter the name of the namespace where the workload will be deployed:

my-namespace
  1. Click Submit

After submitting the new workload specs, the values editor will be shown. Here you can edit the chart values.

  1. Click on Edit

  2. Add the following (minimal) values:

fullnameOverride: hello-deploy
image:
  repository: otomi/nodejs-helloworld
  tag: v1.2.13

  1. Click on Submit

  2. Click on Deploy Changes (the Deploy Changes button in the left panel will light-up after you click on submit).

Publicly expose a service deployed in any namespace​

The Services in team-admin can be used to publicly expose services deployed in any namespace. The only requirement is that the namespace has the label istio-injection: enabled.

Let's now configure public exposure for the workload we deployed in the namespace my-namespace:

  1. In the left menu panel under click Services then click on Create Service

  2. Fill in the name of the Kubernetes service (hello-deploy) that you already deployed

  3. Fill in the namespace where the service is deployed (my-namespace in this example)

  4. Fill in the port of the service (8080 in this case)

  5. Under Exposure Ingress, select Ingress

  6. Turn off Use team domain and fill in the name of the service as the hostname (hello-deploy in this example)

  7. Click on Submit

  8. Click on Deploy Changes (the Deploy Changes button in the left panel will light-up after you click on submit).

Your service and URL will now show up in the list of Services.

- + \ No newline at end of file diff --git a/docs/for-ops/sre/daily/index.html b/docs/for-ops/sre/daily/index.html index 3f9fb133b..e38421657 100644 --- a/docs/for-ops/sre/daily/index.html +++ b/docs/for-ops/sre/daily/index.html @@ -14,13 +14,13 @@ - +

SRE Daily Routine

As an SRE you would like to keep your daily tasks to a minimum and be automatically informed on issues. Otomi offers the following tooling to automate this:

  • Prometheus is the main monitoring tool, and notifications will be triggered for issues that need attention
  • Loki is used to collect cluster and container logs. Loki will only collect logs and not analyze them, it's up to the user to review the logs. Logs can help find issues that are invisible to monitoring systems
  • Grafana is used to visualize metrics, it can help you analyze issues with performance. (Note that we don't use its alerting capabilities.) Its historical data can help in pinpointing resource conflicts over time
  • Prometheus BlackBox exporter is a service probing tool used by Prometheus to periodically probe services over HTTP, TCP, UDP, and ICMP. When it receives non-valid responses it will trigger an alert

Otomi makes use of Slack (but MS Teams and email can also be configured) as the main notifications channel. Subscribe to the configured channels.

Steps to perform​

  • [ONGOING] Keep a close eye on the #mon-* channels in Slack, it will show all Alertmanager notifications
  • [ONGOING] Proactively monitor things not automatically detected (see the following steps)

Since not everything is monitored it is necessary to log in to certain systems and look:

  • Check k9s (or kubectl top nodes) for current cluster resource usage
  • Check Grafana for cluster resource and disk usage
  • Check Loki for stderr messages on the cluster
  • Check if pods are restarting over and over
  • Check if operators are working. (some operators stop working after a while, the Istio operator is an important component)
  • Check for cluster events (kubectl get events -A) on all nodes and validate if any pods have issues
  • [PERIODICALLY] Check if Prometheus (BlackBox) rules are correct
  • [OPTIONAL] Check if a backup is available for state data
- + \ No newline at end of file diff --git a/docs/for-ops/sre/overview/index.html b/docs/for-ops/sre/overview/index.html index a1f3a70cf..b5b9a81ea 100644 --- a/docs/for-ops/sre/overview/index.html +++ b/docs/for-ops/sre/overview/index.html @@ -14,13 +14,13 @@ - +

SRE Overview

Otomi is a set of functions built on top of a suite of pre-configured and integrated open source applications. Instead of selecting, configuring, and integrating all the parts that are needed to securely manage containerized applications in multi- and hybrid environments, Otomi offers all required parts in a single package. Otomi can be seen as any other Kubernetes application or add-on, with the difference that Otomi is pre-configured and offers a higher abstraction of configuration for all the integrated solutions. All integrated applications can however be used freely, meaning that a user can benefit from the pre-configuration to start using the offered applications.

The user controls the configuration of all objects installed by Otomi, based on the values schema provided by Otomi, and the user controls the full configuration of all Kubernetes objects deployed. Lets take a closer look:

Reference configuration​

Otomi provides a reference configuration (Otomi Values) that can be used as a quick-start to install and configure a complete suite of integrated open source applications, an advanced ingress architecture, multi-tenancy, developer self-service, and implemented security best-practices. The reference configuration can be modified using the Otomi Console and Otomi API, based on a pre-defined value schema. SRE can change and optimize the reference configuration when needed. There are 2 supported options:

  • Standard, using the Otomi values schema to modify the configuration
  • Advanced, customization using overrides

Let's take a closer look at both options.

Standard​

Out-of-the-box, Otomi comes with an extensive values schema (see here). Most of the standard values (platform configuration) can be modified using Otomi Console. Changes made through the console are translated into configuration code (based on the values schema). Schema-supported values that can not be changed using the Otomi Console, can be modified in the Otomi Values repository (default Gitea is installed, but an external repository like Github is also supported). Otomi supports Visual Studio Code integration for autocompletion based on the Otomi schema. The Otomi values schema supports the most common use-cases when working with Kubernetes.

Advanced​

For advanced use-cases, configuration values of all integrated open source applications can be customized. Together with the fully integrated observability suite, SRE can pro-actively monitor the resource usage of the integrated open source applications (like Istio and Ingress NGINX) and optimize the configuration when needed.

The Otomi values schema, in this case, can be overridden by custom configuration values. Custom configuration values can be all values supported by the charts of the integrated open source applications in Otomi Core.

SRE can use Otomi Console to change configuration settings (like security policies), but can also change the Otomi Values directly using the Otomi values schema and by using overrides. In all cases, the configuration is stored in code (the otomi-values repository).

The following code shows the configuration values of the ingress-nginx chart.

charts:
  ingress-nginx:
    private:
      enabled: false
    modsecurity:
      enabled: true
      owasp: true
    _rawValues:
      controller:
        config:
          error-log-level: info

Line 1-7 are configuration options supported in the Otomi values schema. Line 8-11 are used to add specific (not schema supported) configuration values using overrides (rawValues).

Guides & checklists​

For SRE's we have created a couple of guides and checklists:

- + \ No newline at end of file diff --git a/docs/for-ops/sre/troubleshooting/index.html b/docs/for-ops/sre/troubleshooting/index.html index 1cb55b5c6..1ec9df614 100644 --- a/docs/for-ops/sre/troubleshooting/index.html +++ b/docs/for-ops/sre/troubleshooting/index.html @@ -14,14 +14,14 @@ - +

SRE Troubleshooting Checklist

Pods not starting​

Pods that are unable to start do not show any log output, the issue is related to k8s. Look for a pod with status Pending. Most of the time this is related to resources and container component issues.

  • Describe the pod, look closely at listed events
  • Is the image pullable? Is there a pull secret configured?
  • Can volumes, configmaps and secrets be mounted?
  • Check resource requests: is the requested resource available?
  • Are commands and arguments correct? (make sure to use /bin/sh -c as command to use ENV)
  • Does the cluster have enough resources available?

Advanced​

  • Check affinity and node selector rules
  • Is the image tag valid and compatible with the host CPU? (exec format error)
  • Check namespace quotas for pod, cm or secret limits etc.
  • Check service account and permissions
  • Is the pod a job, deployment, daemonset or statefulset?
  • Is there a limitrange configured in the namespace?
  • Is the template spec in the pod matching the running container?

Pods not running​

Pods that are running but restart for whatever reason indicate that a container itself is having issues. Look for pod status Crashloop, OOMkilled or incomplete ready status (2/3)

  • Check if dns resolving works
  • Are the required services available to the pod?
  • Check restart count and inspect logs and previous logs
  • Check if istio injection is required and working
  • Is a lifecycle spec configured?
  • Does the container depend on sidecar containers?
  • Check for available resources requests
  • Check readiness and liveness probes
  • Does the pod have enough CPU resources to do it's job?
  • Inspect the restart counter for the pod, a high value (32+) indicates an unstable pod

Advanced​

  • Check pod's service account permissions
  • Attach shell and inspect container status
  • Rootless containers need special care combined with volumes
  • Check securitycontext and pod security policy
  • Check volume permissions

Network services not working​

Pods are working but a user can't connect to the service. Most HTTP-based services use an Ingress object, non HTTP services require a service port to be defined.

Network policies or Istio policies can deny pods from communicating, note that DNS resolving is required for normal operation.

  • Check if network policies are too strict by removing suspect one(s) (if so report an issue to have it/them refactored, if not put back)
  • Use kubectl port-forward to debug pod service on lowest level
  • Check if kube-dns / coredns pods are working in kube-system namespace
  • Check invalid DNS names, too long (64+) or invalid characters
  • Attach a shell and perform basic nslookup or ping commands (ping doesn't work between internal services in k8s)
  • Confirm that services do not mix http and https in frontend and backend
  • Service names matter, prefix accordingly with http- or https- for istio to recognize
  • Validate ingress, istio gateway, virtual service and services

Advanced​

  • heck for network policies
  • Validate istio pods are working
  • Check if istio injection is configured and working
  • Validate istio-operator working
  • Run istioctl analyze

Istio issues​

Istio sidecars manipulate the container's network to reroute traffic. A namespace can have an Istio sidecar policy indicated by a label, the same is valid for a deployment or pod. Make sure you see Istio sidecars running when applicable (indicated by the 3/3 Ready status).

  • Check if istio-operator is working
  • Check logs for istiod pods
  • Are services correctly named? (istio treats http- prefix and https- prefix differently)
  • Check logs for istio sidecar proxy
  • Check if mtls is enabled and working

Advanced​

  • Is the correct service account configured?
  • Is Istio mTLS enabled and configured correctly?
  • Turn on logging for a context of an istio sidecar: ksh exec -it $container_id -c istio-proxy -- sh -c 'curl -k -X POST localhost:15000/logging?jwt=debug'

DNS issues​

The external-dns service is registering DNS names to makes sure that the service names are publicly available.

  • Make sure external-dns logs indicate All records are already up to date
  • Are the credentials configured correctly?

Certificate issues​

  • Check cert-manager working
  • Run kubectl describe orders.acme.cert-manager.io -A
  • Run kubectl describe challenges.acme.cert-manager.io -A
  • Run kubectl describe certificates.cert-manager.io -A

Storage issues​

Check available storage classes std and fast exist

The otomi-pipeline pipeline failure​

In the otomi-pipeline execution failure, read carefully last few lines from the PipelineRun`` output. Errors containing: unable to build kubernetes objects from release manifest: Get "https://10.32.0.1:443/openapi/v2?timeout=32s": net/http: request canceledstring, indicates that the kube-api was not available. Admin can restart the pipeline by triggering webhook from Gitea app. Go to otomi/values repository -> click Settings-> select Webhookstab -> click the Test Delivery` button.

Advanced​

  • Describe pv and pvc, check if pv's are rwo or rwx and look for conflicts
  • Check if container expects or rwx pv

Contact support (Enterprise subscription required)​

In case (after troubleshooting) the customer discovers one of the Otomi functions is not working as expected, an issue can be reported. When reporting an issue the following information needs to be provided:

  • Is the function not working in only a single case, or in all cases?
  • Which function is not working?
  • Which remediation activities have been performed?
  • kubeLog output of the container(s) supporting this function

In case the issue is caused by a bug in one of the Otomi features, then Red Kubes will provide a fix within at least 24 hours.

- + \ No newline at end of file diff --git a/docs/for-ops/sre/upgrades/index.html b/docs/for-ops/sre/upgrades/index.html index 5d5244487..f55d408ca 100644 --- a/docs/for-ops/sre/upgrades/index.html +++ b/docs/for-ops/sre/upgrades/index.html @@ -14,13 +14,13 @@ - +

Upgrades

Introduction​

Since otomi-core is a mono repo with many open source charts that are working together, it is very hard to coordinate updates to its parts. Luckily we can rely on a lot of smart operators to take care of upgrades (we strive to only adopt operators with capability level "Seamless Upgrades"), but some scripting is always needed in this case. We strive to make upgrades as painless as possible by creating upgrade scripts for the release versions.

Example: in order to migrate from v0.10.* to v0.11.* you would run bin/upgrades/v0.11.sh. Soon the upgrade scripts can also be used to migrate from an older version, as it will apply any in between upgrade scripts successively.

In some situations however, the automatic upgrades will throw an error, and might require removing/patching existing resources before helm can adopt or manipulate them. Notable issues:

  • Resources not under helm chart control: since helm 3.2 these can be adopted. When trying to deploy helm resources over existing resources helm will give detailed instructions on how to adopt these.
  • Some resources have labels and do not allow changing them. This usually points to bad chart practices, but mandates removal before recreating these resources. This can't always be done and is a big drawback. Remedies usually exist but might have to be investigated on the fly.

Steps to upgrade otomi-core​

So every time an upgrade of the stack is released it is important to follow these steps:

  1. Read the release notes on otomi-core for impact and special cases.
  2. Check the corresponding upgrade script(s) and read the comments. It might involve manual steps.
  3. Set the new version tag in clusters.yaml and run otomi bootstrap to pull in latest artifacts
  4. Do a diff first: otomi diff
  5. Run the upgrade script
  6. Check the output and fix anything that needs fixing and repeat steps 4-6
  7. Commit the values when all is well and the Otomi Tekton pipeline will take it from there
- + \ No newline at end of file diff --git a/docs/get-started/activation/index.html b/docs/get-started/activation/index.html index ac4facf4a..7da72066d 100644 --- a/docs/get-started/activation/index.html +++ b/docs/get-started/activation/index.html @@ -14,13 +14,13 @@ - +

Activation steps

Follow the steps below to activate Otomi after initial installation.

Step 1: Get the log output of the installer job​

When the installer job (in the default namespace) has finished, copy the URL and the generated password from the bottom of the logs, sign in to the console with the provided URL, username and password.

Use the following command to get the logs of the installer job:

kubectl logs jobs/otomi -n default -f

Step 2: Create an License Key for using Otomi Console and Otomi API​

info

A Community Edition License Key is required per 17-05-2023

If you would like to use the Otomi Console (Web UI) and Otomi API (for code validation and creation), then you will first need to create a Community Edition License key in Otomi Cloud. Follow these instructions to create a License Key:

  • Go to Otomi Cloud
  • Create an account
  • Click on Register Cluster
  • Agree with the EULA
  • Copy the License Key and click Continue
  • Log in to Otomi Console. You can find the link in the logs of the installer (see step 1)
  • Add the License key to Otomi Console
  • Click Activate

Step 3 (optional): Add the auto generated CA to your keychain​

Otomi by default automatically generates a CA. The generated CA is of course not trusted on your local machine. Here are some options to prevent you from clicking away lots of security warning in your browser:

  1. In the left menu of the console, click on "Download CA"
  2. Double click the downloaded CA.crt or add the CA to your keychain on Mac using the following command:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/Downloads/ca.crt

On Windows, use PowerShell (running as Administrator) with the Certutil:

certutil.exe -addstore root <downloaded cert path>

Or:

Import-Certificate -FilePath "<downloaded cert path>" -CertStoreLocation Cert:\LocalMachine\Root
# Restart the browser

But you could also run Chrome in insecure mode:

alias chrome-insecure='/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors --ignore-urlfetcher-cert-requests &> /dev/null'
  1. Optional: Restart Docker (to support pushing images to Harbor)

Step 4 (Optional): Create a new admin user​

ATTENTION

We strongly advise to not use the default otomi-admin account after activation and to not change the password. Store it somewhere safe and only use it in case absolutely required.

Create a new user account in Keycloak and add the new user to the otomi-admin and team-admin group.

Step 5 (Optional): Add the URL of the Kubernetes API​

NOTE

Adding the URL of the K8s cluster API is required by teams to be able to download the KUBECONFIG

  • Under Platform in Otomi Console, click on Settings
  • Click on Cluster
  • Add the full URL of the API server
  • Click on Submit
  • Click on Deploy Changes
- + \ No newline at end of file diff --git a/docs/get-started/chart/index.html b/docs/get-started/chart/index.html index cd9dc5284..5f27c5535 100644 --- a/docs/get-started/chart/index.html +++ b/docs/get-started/chart/index.html @@ -14,13 +14,13 @@ - +

Install from chart

Use Helm to install Otomi.

Visit the helm documentation page for more details on how to work with helm charts.

Before you begin verify if you have met the prerequisites

Add the Otomi repository​

helm repo add otomi https://otomi.io/otomi-core
helm repo update

See helm repo for command documentation.

Default install​

cluster:
  name: # the name of your cluster
  provider: # choose between aws, azure, google, digitalocean, ovh, vultr, scaleway or custom

Custom values​

To view the required values.yaml file with detailed comments, view and download the chart's latest values.yaml. Run the following command to view all the values (which might be overwhelming):

helm show values otomi/otomi

To test wether the input values are correct run the following command:

helm template -f values.yaml otomi/otomi

Install the Chart​

Install the chart with the following command:

helm install -f values.yaml otomi otomi/otomi

Monitoring the Chart install​

The chart deploys a Job (otomi) in the default namespace. Monitor the chart install using kubectl:

# get the status of the job
kubectl get job otomi -w
# watch the helm chart install status:
watch helm list -Aa

Or view detailed info about kubernetes resources with k9s

Next steps​

Once Otomi is installed, follow the activation steps to get ready to use Otomi.

Installing from source​

As an alternative, you can also clone the otomi-core source code from the Github and install otomi using the chart source code.

Download source​

git clone https://github.com/redkubes/otomi-core.git
cd otomi-core

Install from source​

Now customize the values.yaml file. See configuration below for more details.

Use the following command to install the chart with the name my-otomi-release (a custom name that you choose).

helm install -f values.yaml my-otomi-release chart/otomi

Uninstalling the Chart​

helm uninstall my-otomi-release

Doing a Helm uninstall will only remove the job used to deploy Otomi. It will not remove all the installed components. If you would like to do a complete uninstall, we advise to first clone the otomi/values repository (to secure the configuration) and then uninstall using Otomi CLI.

- + \ No newline at end of file diff --git a/docs/get-started/installation/aws/index.html b/docs/get-started/installation/aws/index.html index 9af1cb8f4..3ad03063c 100644 --- a/docs/get-started/installation/aws/index.html +++ b/docs/get-started/installation/aws/index.html @@ -14,13 +14,13 @@ - +
-

Install Otomi on EKS with DNS using Route53

Prerequisites​

Additional resources​

AWS CLI Cheat Sheet
# Obtain account
aws sts get-caller-identity
# Obtain username and userarn
aws iam get-user
# Obtain rolearn
aws iam list-roles
# Obtain groups
aws iam list-groups

Create an EKS cluster​

Clone the Otomi Terraform repository:

git clone https://github.com/redkubes/quickstart.git
cd eks
  • Copy example.tfvars file to terraform.tfvars file and fill in missing configuration parameters
  • Open a terminal and run the following:
terraform init
# install the EKS cluster
terraform apply

Get the credentials of the cluster:

# Update your kubeconfig
# Default: aws eks update-kubeconfig --name otomi
aws eks update-kubeconfig --name <cluster_name>

Add a CNI​

To use the network policies feature in Otomi, make sure to install the Calico CNI or any other CNI that supports Kubernetes network polices.

Install Tigera Operator:

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm repo update
kubectl create namespace tigera-operator
helm install calico projectcalico/tigera-operator --version v3.26.3 --namespace tigera-operator

Or install Calico minimal:

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico.yaml

Configure Route53​

Follow these steps to use AWS Route53.

  1. Register a domain and retrieve the Hosted zone ID
  2. Create a dns-policy.json file for the policy and add the Zone ID:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "route53:GetChange",
            "Resource": "arn:aws:route53:::change/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Resource": [
                "arn:aws:route53:::hostedzone/<your-zone-id>"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ListHostedZonesByName",
                "route53:ListHostedZones"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}
  1. Create the policy:
aws iam create-policy --policy-name "otomi-dns" --policy-document file://dns-policy.json
  1. export the policy ARN:
export POLICY_ARN=$(aws iam list-policies --query 'Policies[?PolicyName==`<policy-name>`].Arn' --output text)
  1. Create a user:
USER=user-name
aws iam create-user --user-name $USER
  1. Attach the user to the policy:
aws iam attach-user-policy --user-name $USER --policy-arn $POLICY_ARN
  1. Create the access-key:
ACCESS_KEY=$(aws iam create-access-key --user-name $USER)
  1. Get the secret-access-id and secret-access-key:
ACCESS_KEY_ID=$(echo $ACCESS_KEY | jq -r '.AccessKey.AccessKeyId')
ACCESS_KEY_SECRET=$(echo $ACCESS_KEY | jq -r '.AccessKey.SecretAccessKey')

Create the values.yaml file​

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: aws
  region: your-region
  apiName: api-server-endpoint
  domainSuffix: your-domain.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - your-domain.com
  provider:
    aws:
      credentials:
        secretKey: $ACCESS_KEY_ID
        accessKey: $ACCESS_KEY_SECRET
      region: your-region
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@your-domain.com
EOF

Install Otomi on EKS​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- +

Install Otomi on EKS with DNS using Route53

Prerequisites​

Additional resources​

AWS CLI Cheat Sheet
# Obtain account
aws sts get-caller-identity
# Obtain username and userarn
aws iam get-user
# Obtain rolearn
aws iam list-roles
# Obtain groups
aws iam list-groups

Create an EKS cluster​

Clone the Otomi Terraform repository:

git clone https://github.com/redkubes/quickstart.git
cd eks
  • Copy example.tfvars file to terraform.tfvars file and fill in missing configuration parameters
  • Open a terminal and run the following:
terraform init
# install the EKS cluster
terraform apply

Get the credentials of the cluster:

# Update your kubeconfig
# Default: aws eks update-kubeconfig --name otomi
aws eks update-kubeconfig --name <cluster_name>

Add a CNI​

To use the network policies feature in Otomi, make sure to install the Calico CNI or any other CNI that supports Kubernetes network polices.

Install Tigera Operator:

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm repo update
kubectl create namespace tigera-operator
helm install calico projectcalico/tigera-operator --version v3.26.3 --namespace tigera-operator

Or install Calico minimal:

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico.yaml

Configure Route53​

Follow these steps to use AWS Route53.

  1. Register a domain and retrieve the Hosted zone ID
  2. Create a dns-policy.json file for the policy and add the Zone ID:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "route53:GetChange",
            "Resource": "arn:aws:route53:::change/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Resource": [
                "arn:aws:route53:::hostedzone/<your-zone-id>"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "route53:ListHostedZonesByName",
                "route53:ListHostedZones"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}
  1. Create the policy:
aws iam create-policy --policy-name "otomi-dns" --policy-document file://dns-policy.json
  1. export the policy ARN:
export POLICY_ARN=$(aws iam list-policies --query 'Policies[?PolicyName==`<policy-name>`].Arn' --output text)
  1. Create a user:
USER=user-name
aws iam create-user --user-name $USER
  1. Attach the user to the policy:
aws iam attach-user-policy --user-name $USER --policy-arn $POLICY_ARN
  1. Create the access-key:
ACCESS_KEY=$(aws iam create-access-key --user-name $USER)
  1. Get the secret-access-id and secret-access-key:
ACCESS_KEY_ID=$(echo $ACCESS_KEY | jq -r '.AccessKey.AccessKeyId')
ACCESS_KEY_SECRET=$(echo $ACCESS_KEY | jq -r '.AccessKey.SecretAccessKey')

Create the values.yaml file​

  • Get the API server endpoint. You can find the API server endpoint in the Details section of the cluster in the AWS console.

  • Add the DNS configuration created in the previous step, the API server endpoint, the domainSuffix, domainFilters, region and email to the values.yaml that we'll use to install Otomi:

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: aws
  region: your-region
  apiName: api-server-endpoint
  domainSuffix: your-domain.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - your-domain.com
  provider:
    aws:
      credentials:
        secretKey: $ACCESS_KEY_ID
        accessKey: $ACCESS_KEY_SECRET
      region: your-region
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@your-domain.com
EOF

Install Otomi on EKS​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

+ \ No newline at end of file diff --git a/docs/get-started/installation/azure/index.html b/docs/get-started/installation/azure/index.html index af22225cf..f92d23f02 100644 --- a/docs/get-started/installation/azure/index.html +++ b/docs/get-started/installation/azure/index.html @@ -14,13 +14,13 @@ - +

Install Otomi on AKS with DNS

Prerequisites​

Note: If you login via Azure Cloud Shell, you don't need to install the prerequisites

Azure CLI Cheat Sheet

# Sign in to Azure
az login
# Get a list of subscriptions for the logged in account
az account list
# Set subscription
az account set --subscription=<subscription_id>

Create an AKS cluster​

Setting the environment variables

# Set Resource Group Name 
RGNAME=rg-otomi
# Set Region (Location) or any other location
LOCATION=westeurope
# Create Resource Group
az group create -n $RGNAME -l $LOCATION
# Set Cluster name
CLUSTER_NAME=otomi

Creating the cluster

# Create AKS cluster
az aks create --name $CLUSTER_NAME \
--resource-group $RGNAME \
--location $LOCATION \
--zones 1 2 \
--vm-set-type VirtualMachineScaleSets \
--nodepool-name otomipool \
--node-count 3 \
--node-vm-size Standard_F8s_v2 \
--kubernetes-version 1.27.3 \
--enable-cluster-autoscaler \
--min-count 1 \
--max-count 6 \
--max-pods 100 \
--network-plugin azure \
--network-policy calico \
--outbound-type loadBalancer \
--generate-ssh-keys

Update the Kubernetes config file

az aks get-credentials -n $CLUSTER_NAME -g $RGNAME

Configure DNS​

Create an Azure DNS zone​

  • Create a resource group:
$ az group create --name "MyDnsResourceGroup" --location $LOCATION
  • Create a Azure DNS zone for example.com:
$ az network dns zone create --resource-group "MyDnsResourceGroup" --name "example.com"

Substitute a domain you own for example.com if desired.

If using your own domain that was registered with a third-party domain registrar, you should point your domain's name servers to the values in the nameServers field from the JSON data returned by the az network dns zone create command. Please consult your registrar's documentation on how to do that.

Create a Service Principal​

Create a Service Principal with a minimum access level of DNS Zone Contributor or Contributor to the DNS zone(s) and Reader to the resource group containing the Azure DNS zone(s).

$ DNS_NEW_SP_NAME="ExternalDnsServicePrincipal" # name of the service principal
$ AZURE_DNS_ZONE_RESOURCE_GROUP="MyDnsResourceGroup" # name of resource group where dns zone is hosted
$ AZURE_DNS_ZONE="example.com" # DNS zone name like example.com or sub.example.com

# Create the service principal
$ DNS_SP=$(az ad sp create-for-rbac --name $DNS_NEW_SP_NAME)
$ DNS_SP_APP_ID=$(echo $DNS_SP | jq -r '.appId')
$ DNS_SP_PASSWORD=$(echo $DNS_SP | jq -r '.password')

Grant access to Azure DNS zone for the service principal.

# fetch DNS id used to grant access to the service principal
DNS_ID=$(az network dns zone show --name $AZURE_DNS_ZONE \
 --resource-group $AZURE_DNS_ZONE_RESOURCE_GROUP --query "id" --output tsv)

# 1. as a reader to the resource group
$ az role assignment create --role "Reader" --assignee $DNS_SP_APP_ID --scope $DNS_ID

# 2. as a contributor to DNS Zone itself
$ az role assignment create --role "Contributor" --assignee $DNS_SP_APP_ID --scope $DNS_ID

Create the values.yaml file​

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: azure
  domainSuffix: azure.example.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - example.com
  provider:
    azure:
      resourceGroup: $AZURE_DNS_ZONE_RESOURCE_GROUP
      aadClientId: $DNS_SP_APP_ID
      aadClientSecret: $DNS_SP_PASSWORD
      tenantId: "$(az account show --query tenantId -o tsv)"
      subscriptionId: "$(az account show --query id -o tsv)"
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@example.com
EOF

And adjust the domainSuffix, domainFilters and email.

Install Otomi using helm​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- + \ No newline at end of file diff --git a/docs/get-started/installation/byo-wildcard-cert/index.html b/docs/get-started/installation/byo-wildcard-cert/index.html index 70ee3c0de..a3fbc0e6a 100644 --- a/docs/get-started/installation/byo-wildcard-cert/index.html +++ b/docs/get-started/installation/byo-wildcard-cert/index.html @@ -14,13 +14,13 @@ - +

BYO Wild card Certificate

When installing Otomi with DNS, there are 3 issuers you can use:

  1. custom-ca
  2. letsencrypt
  3. byo-wildcard-cert

In most of the installation examples we use letsencrypt. In this example we'll show how to use a Bring Your Own wildcard certificate.

To use a byo-wildcard-cert, install otomi with the following values:

cluster:
  name: otomi
  provider: aws # adjust to your provider
  domainSuffix: try-otomi.net
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - try-otomi.net
  provider:
    aws:
      credentials:
        secretKey: xxx
        accessKey: xxx
      region: eu-central-1
apps:
  cert-manager:
    issuer: byo-wildcard-cert
    # Add the full chain of your wild card certificate
    byoWildcardCert: |
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----
      -----BEGIN CERTIFICATE-----
      -----END CERTIFICATE-----
    byoWildcardCertKey: |
      -----BEGIN PRIVATE KEY-----
      -----END PRIVATE KEY-----
- + \ No newline at end of file diff --git a/docs/get-started/installation/civo/index.html b/docs/get-started/installation/civo/index.html index 865e2dadd..9bb31c87b 100644 --- a/docs/get-started/installation/civo/index.html +++ b/docs/get-started/installation/civo/index.html @@ -14,13 +14,13 @@ - +

Civo

ATTENTION

Otomi can also be installed using the Civo marketplace. When Otomi is installed using the Civo marketplace, Otomi is installed without DNS! To see the full potential of Otomi, install Otomi with DNS as described here.

Install Otomi on Civo with DNS

Create a K3s cluster in Civo​

  1. Sign in to the Civo dashboard
  2. Click on Kubernetes in the left menu
  3. Click Create new cluster
  4. Provide a name for the cluster
  5. Select the Standard Large node pool size (3 nodes)
  6. Configure Network and Firewall
  7. Show advanced options
  8. Choose Flannel, Cluster type K3S and Kubernetes version 1.27.1
  9. In the Marketplace, under Architecture, de-activate Traefik v2 (NodePort)
  10. Click Create cluster

Configure DNS​

Set up DNS in Civo:

  1. Under Networking in the Civo Dashboard, click DNS and then Add a domain name
  2. Fill in a domain name and then click Add domain
  3. Create a NS record in the zone where your domain is hosted and add the Civo name servers ns0.civo.com ans ns1.civo.com
  4. Under Settings, Profile, click on the tab Security and copy the API key

Add the API key to your environment variables:

CIVO_TOKEN="<your-api-key>"

Create the values.yaml file​

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: civo
  domainSuffix: civo.example.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - example.com
  provider:
    civo:
      apiToken: $CIVO_TOKEN
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@your-domain.com
EOF

And adjust the domainSuffix, domainFilters and email.

Install Otomi​

ALERT

There are some known issues when installing Otomi on Civo. Check them here

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- + \ No newline at end of file diff --git a/docs/get-started/installation/custom/index.html b/docs/get-started/installation/custom/index.html index 5f6ee04a7..4cf648c30 100644 --- a/docs/get-started/installation/custom/index.html +++ b/docs/get-started/installation/custom/index.html @@ -14,13 +14,13 @@ - +

Install Otomi using the custom provider

To install Otomi on any other cloud or infrastructure platform, use the custom provider in Otomi. Make sure your infrastructure adheres to the following pre-requisites:

Kubernetes versions​

Otomi currently supports the following Kubernetes versions:

  • 1.25
  • 1.26
  • 1.27

Compute resources​

Otomi requires a node pool with at least 8 vCPU and 16 GiB RAM. Note that this is the requirements for a minimal install. When activating more apps, you'll probably need more resources.

ATTENTION

The minimal resource requirement to run Otomi is based on running Core Apps only! The core apps provide an advanced ingress architecture based on Nginx, Istio, Keycloak, Oaut2 Proxy and Certmanager. Activating optional apps will require more compute resources. We advise to have a node pool available with 16 vCPU and 24 GiB memory.

Default storage class​

The custom provider uses the default storage class. If your cluster has a storage class, make sure it is set to be the default:

kubectl patch storageclass ,your-storage-class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

External IP​

Otomi needs to be able to create a Kubernetes LoadBalancer Service that obtains an external IP. This IP needs to be accessible from within the cluster. Use Metallb for on-prem installations to allow Otomi to create a LoadBalancer Service:

# Install Metallb with Helm
kubectl create namespace mlb
helm repo add metallb https://metallb.github.io/metallb
helm repo update
helm install metallb metallb/metallb -n mlb

sleep 60
# Create the IPAddressPool and L2Advertisement
cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-pool
  namespace: mlb
spec:
  addresses:
  - <start-ip>-<end-ip>
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default-pool
  namespace: mlb
EOF

CNI​

To use the network policies feature in Otomi, make sure to install the Calico CNI or any other CNI that supports Kubernetes network polices.

Install Tigera Operator:

helm repo add projectcalico https://docs.tigera.io/calico/charts
helm repo update
kubectl create namespace tigera-operator
helm install calico projectcalico/tigera-operator --version v3.26.3 --namespace tigera-operator

Or install Calico minimal:

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico.yaml

API certificates​

If your cluster uses untrusted certificates, make sure to set metrics-server for kubelet-insecure-tls:

apps:
  metrics-server:
    extraArgs:
      kubelet-insecure-tls: true
      kubelet-preferred-address-types: InternalIP

Install Otomi using the Helm chart​

To install Otomi using the custom provider, use the following values:

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: custom
# optionally configure metrics-server for kubelet-insecure-tls
apps:
  metrics-server:
    extraArgs:
      kubelet-insecure-tls: true
      kubelet-preferred-address-types: InternalIP
EOF

The custom Otomi provider can be used in combination with any DNS provider.

- + \ No newline at end of file diff --git a/docs/get-started/installation/digitalocean/index.html b/docs/get-started/installation/digitalocean/index.html index 929ba0f33..684c1652e 100644 --- a/docs/get-started/installation/digitalocean/index.html +++ b/docs/get-started/installation/digitalocean/index.html @@ -14,13 +14,13 @@ - +

Installing Otomi using the Digital Ocean marketplace

Otomi can be installed as a 1-click-app on DigitalOcean marketplace. You can find the install instructions here.

ATTENTION

Otomi can also be installed using the Digital Ocean marketplace. When Otomi is installed using the Digital Ocean marketplace, Otomi is installed without DNS! To see the full potential of Otomi, install Otomi with DNS as described here.

Prerequisites​

Create a Kubernetes cluster​

Create a Kubernetes cluster using doctl:

doctl kubernetes cluster create otomi --count 3 --region ams3 --size s-4vcpu-8gb --version 1.27.6-do.0

Other options to create a Kubernetes cluster in Digital Ocean using:

Configure DNS​

Creating a DigitalOcean DNS zone​

If you want to learn about how to use DigitalOcean's DNS service read the following tutorial series:

An Introduction to Managing DNS, and specifically How To Set Up a Host Name with DigitalOcean DNS

Create a new DNS zone where you want to create your records in. Let's use example.com as an example here.

Creating DigitalOcean Credentials​

Generate a new personal token by going to the API settings or follow How To Use the DigitalOcean API v2 if you need more information. Give the token a name and choose read and write access.

DO_TOKEN="<your-token>"

Create the values.yaml file​

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: digitalocean
  domainSuffix: do.example.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - example.com
  provider:
    digitalocean:
      apiToken: $DO_TOKEN
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@example.com
EOF

And adjust the domainSuffix, domainFilters and email.

Install Otomi using helm​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- + \ No newline at end of file diff --git a/docs/get-started/installation/entrypoint/index.html b/docs/get-started/installation/entrypoint/index.html index 5eb5a3f10..76414a912 100644 --- a/docs/get-started/installation/entrypoint/index.html +++ b/docs/get-started/installation/entrypoint/index.html @@ -14,13 +14,13 @@ - +

Install Otomi with entrypoint

In some cases, the Kubernetes cluster will de deployed in a private setup where public access is only possible using an external gateway or firewall.

Use case​

When Otomi is installed on a private Kubernetes cluster and services are exposed on a private load balances, we would like to create host names in Otomi and configure DNS entries to point to an external gateway.

For this you can use an entrypoint in Otomi. The entrypoint is a public IP address that will override the (loadbalancer) IP used for registering hosts. This allows public access to private clusters through an external gateway.

To configure an entrypoint, add the following to the values.yaml when installing Otomi:

ingress:
  platformClass:
    entrypoint: <entrypoint-ip-address>

Make sure the external gateway is configured to connect to the IP of the private load balancer used by the platformClass ingress controller.

The DNS A records created by Otomi will now all point to the IP address of the external gateway.

- + \ No newline at end of file diff --git a/docs/get-started/installation/gcp/index.html b/docs/get-started/installation/gcp/index.html index b7ab86873..e3720ae5f 100644 --- a/docs/get-started/installation/gcp/index.html +++ b/docs/get-started/installation/gcp/index.html @@ -14,13 +14,13 @@ - +

Install Otomi on GKE with a GCP DNS zone

Prerequisites​

Note: If you login via Google Cloud Shell, you don't need to install the prerequisites

GCloud CLI Cheat Sheet

# Initialize and authentication
gcloud init
gcloud auth login
gcloud config set project PROJECT_ID

# Enable google services api
gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com

Create a GKE cluster​

Set up environment variables:

info

Change the Machine Type to match a type supported in your region.

# Set Cluster name
CLUSTER_NAME=otomi
# Set region
COMPUTE_REGION=europe-west4
# Set machine type
MACHINE_TYPE=e2-standard-8

Create the cluster:

gcloud container clusters create $CLUSTER_NAME \
    --enable-autoscaling \
    --enable-network-policy \
    --num-nodes 1 \
    --min-nodes 1 \
    --max-nodes 2 \
    --machine-type $MACHINE_TYPE \
    --logging NONE \
    --monitoring NONE \
    --region $COMPUTE_REGION

Update the Kubernetes config file

gcloud container clusters get-credentials $CLUSTER_NAME --region $COMPUTE_REGION

Configure DNS​

Create Cloud DNS Zone​

Create a DNS zone which will contain the managed DNS records. If using your own domain that was registered with a third-party domain registrar, you should point your domain's name servers to the values under the nameServers key. Please consult your registrar's documentation on how to do that. This tutorial will use example domain of example.com.

gcloud dns managed-zones create "example-com" --dns-name "example.com." \
  --description "Automatically managed zone by kubernetes.io/external-dns"

Make a note of the nameservers that were assigned to your new zone.

gcloud dns record-sets list \
    --zone "example-com" --name "example.com." --type NS

Static Credentials​

In this scenario, a new GSA (Google Service Account) is created that has access to the CloudDNS zone. The credentials for this GSA are saved and installed as a Kubernetes secret that will be used by ExternalDNS.

This allows only containers that have access to the secret, such as ExternalDNS to update records on the Cloud DNS Zone.

Create GSA for use with static credentials​

DNS_SA_NAME="external-dns-sa"
DNS_SA_EMAIL="$DNS_SA_NAME@${GKE_PROJECT_ID}.iam.gserviceaccount.com"

# create GSA used to access the Cloud DNS zone
gcloud iam service-accounts create $DNS_SA_NAME --display-name $DNS_SA_NAME

# assign google service account to dns.admin role in cloud-dns project
gcloud projects add-iam-policy-binding $DNS_PROJECT_ID \
  --member serviceAccount:$DNS_SA_EMAIL --role "roles/dns.admin"

Create credentials​

Generate static credentials from the ExternalDNS GSA.

# download static credentials
gcloud iam service-accounts keys create /local/path/to/credentials.json \
  --iam-account $DNS_SA_EMAIL

Get the contents of the credentials.son. Note that you don't need to create a Kubernetes secret. The credentials will be directly provided to the Otomi installer and Otomi will create the secret.

cat /local/path/to/credentials.json
{
    "type": "service_account",
    "project_id": "xxx",
    "private_key_id": "xxx",
    "private_key": xxx,
    "client_email": "external-dns-sa@otomi.iam.gserviceaccount.com",
    "client_id": "000000000000",
    "auth_uri": "https://accounts.google.com/o/oauth2/auth",
    "token_uri": "https://oauth2.googleapis.com/token",
    "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
    "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/xxxx.iam.gserviceaccount.com"
}

Create the values.yaml file​

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: google
  domainSuffix: gcp.example.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - example.com
  provider:
    google:
      serviceAccountKey: |
        {
            "type": "service_account",
            "project_id": "xxx",
            "private_key_id": "xxx",
            "private_key": xxx,
            "client_email": "external-dns-sa@otomi.iam.gserviceaccount.com",
            "client_id": "000000000000",
            "auth_uri": "https://accounts.google.com/o/oauth2/auth",
            "token_uri": "https://oauth2.googleapis.com/token",
            "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
            "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/xxxx.iam.gserviceaccount.com"
        }
      project: $DNS_PROJECT_ID
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@example.com
EOF

And adjust the domainSuffix, domainFilters and email.

Install Otomi using helm​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- + \ No newline at end of file diff --git a/docs/get-started/installation/helm/index.html b/docs/get-started/installation/helm/index.html index 32d8f097d..6830f5868 100644 --- a/docs/get-started/installation/helm/index.html +++ b/docs/get-started/installation/helm/index.html @@ -14,13 +14,13 @@ - +

Install Otomi with Helm

Add the Otomi repository​

helm repo add otomi https://otomi.io/otomi-core
helm repo update

See helm repo for command documentation.

Minimal configuration​

info

As of version 1.0.0 Otomi supports Kubernetes versions 1.25,1.26 and 1.27.

info

The Otomi Builds and Projects features and using Harbor for private registries is NOT supported when Otomi is installed with minimal configuration. Install Otomi with DNS to use all Otomi features.

cluster:
  name: # the name of your cluster
  provider: # choose between aws, azure, google, digitalocean, ovh, vultr, scaleway or custom

When the chart is installed, follow the activation steps.

Custom values​

To view the required values.yaml file with detailed comments, view and download the chart's latest values.yaml. Run the following command to view all the values (which might be overwhelming):

helm show values otomi/otomi

To test wether the input values are correct run the following command:

helm template -f values.yaml otomi/otomi

Install the Chart​

Install the chart with the following command:

helm install -f values.yaml otomi otomi/otomi

Monitoring the chart install​

The chart deploys a Job (otomi) in the default namespace. Monitor the chart install using kubectl:

# get the status of the job
kubectl get job otomi -w
# watch the helm chart install status:
watch helm list -Aa

Or view detailed info about kubernetes resources with k9s

When the chart is installed, follow the activation steps

Installing from source​

As an alternative, you can also clone the otomi-core source code from the Github and install otomi using the chart source code.

Download source​

git clone https://github.com/redkubes/otomi-core.git
cd otomi-core

Before installing the chart from source, first change the CHART_VERSION_PLACEHOLDER in the chart/otomi/Chart.yaml to v1.0.0

Install​

Now customize the values.yaml file. Make sure to set the version to the branch you like to use:

otomi:
  version: main

Use the following command to install the chart with the name my-otomi-release (a custom name that you choose).

helm install -f values.yaml my-otomi-release chart/otomi

Uninstalling Otomi​

helm uninstall my-otomi-release

Doing a Helm uninstall will remove all Helm releases deployed by Otomi. After uninstalling, some namespaces created by Otomi can stay in a Terminating status. To remove all namespaces in a Terminating status, run the following command:

for ns in $(kubectl get ns --field-selector status.phase=Terminating -o jsonpath='{.items[*].metadata.name}'); do kubectl get ns $ns -ojson | jq '.spec.finalizers = []' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -; done
- + \ No newline at end of file diff --git a/docs/get-started/installation/kms/index.html b/docs/get-started/installation/kms/index.html index deffe2724..beb0df03b 100644 --- a/docs/get-started/installation/kms/index.html +++ b/docs/get-started/installation/kms/index.html @@ -14,13 +14,13 @@ - +

Use KMS to manage keys for encryption

If you would like the secrets in the values repository to be encrypted, you will have to setup an account with your Key Management Service (KMS) provider. It is needed by sops, the tool used for encryption.

Find quickstart documentation below on how to setup KMS access per supported provider:

Follow the instructions of the provider of your choosing and jot down the credentials obtained for the next steps.

To install Otomi with SOPS/KMS, use the following values:

kms:
  sops:
    provider: "" # provider can be one of aws|azure|google|vault
#     aws:
#       keys: ''
#       accessKey: ''
#       secretKey: ''
#       region: ''
#     azure:
#       keys: ''
#       tenantID: ''
#       clientID: ''
#       clientSecret: ''
#     google:
#       keys: ''
#       accountJson: ''
#       project: ''
#     vault:
#       token: ''
- + \ No newline at end of file diff --git a/docs/get-started/installation/known-issues/index.html b/docs/get-started/installation/known-issues/index.html index 82ce9574c..b3ce2a4c3 100644 --- a/docs/get-started/installation/known-issues/index.html +++ b/docs/get-started/installation/known-issues/index.html @@ -14,13 +14,13 @@ - +

Known Installation Issues

Metrics server does not start with untrusted Kube API certificates​

Issue

Metrics server will not start when installing on a K8s cluster (like on Minikube or a cluster created with Kubeadm) with Kube API using self-signed certificates

Solution

Add extra args to the metrics-service by using the following values when installing Otomi with Helm chart:

apps:
  metrics-server:
    enabled: true
    _rawValues:
      extraArgs:
        kubelet-preferred-address-types: InternalIP
        kubelet-insecure-tls: true

Namespaces stuck in terminating state when uninstalling Otomi​

Issue

When uninstalling Otomi using the helm unistall cmd, all Otomi namespaces get stuck in a terminating state.

Solution

The work around for now is to delete all namespaces using this cmd:

for ns in $(kubectl get ns --field-selector status.phase=Terminating -o jsonpath='{.items[*].metadata.name}'); do  kubectl get ns $ns -ojson | jq '.spec.finalizers = []' | kubectl replace --raw "/api/v1/namespaces/$ns/finalize" -f -; done

Installing Otomi with DNS fails due to failed authentication for Gitea​

Issue

When installing Otomi with DNS, the installations fails with the following error:

otomi:cmd:commit:commitAndPush:error remote: Unauthorized
fatal: Authentication failed for 'https://gitea.otomi.example.com/otomi/values.git/'

Solution

Provide a custom password:

otomi:
  adminPassword: yourpassword

Installing Otomi on Civo fails​

There can be multiple issues when installing Otomi on Civo:

Issue

Some pods get stuck in a pending state during installation.

Solution

Otomi installs K8s applications like KeyCloak and Gitea. These apps require persistent storage. Civo has default quota set on resources, including volumes. If a pod stays in a pending state, it might be caused by a quota limit. In Civo dashboard, check the amount of volumes and remove all volumes that are not in use. Also check in the amount of volumes did not reach a quota limit and request an increase when needed.

Issue

When installing Otomi using Civo market place on a Linux Talos cluster the Otomi installation fails.

Solution

Installing Otomi on Civo Linux Talos is currently not supported. Try installing Otomi on Civo K3s.

Issue

Keycloak-01 pod is not able to start and the Keycloak logs show the following message: File "base/16385/PG_VERSION" does not contain valid data.

Solution

This issue is still under investigation. For now, first run the following cmd:

kubectl exec -it -n keycloak keycloak-db-1 -c postgres -- sh -c 'echo "15" > /var/lib/postgresql/data/pgdata/base/16385/PG_VERSION'

and then delete the keycloak-0 pod:

kubectl delete pod keycloak-0 -n keycloak

Keycloak should now start.

- + \ No newline at end of file diff --git a/docs/get-started/installation/linode/index.html b/docs/get-started/installation/linode/index.html index 30fc71f50..0465d6b6e 100644 --- a/docs/get-started/installation/linode/index.html +++ b/docs/get-started/installation/linode/index.html @@ -14,13 +14,13 @@ - +

# Install Otomi on Linode Kubernetes Engine (LKE) with Linode DNS

Prerequisites​

Configure Linode Kubernetes cluster​

Configure the LKE cluster with the following specs

  • K8s version: 1.27
  • Enable HA Control Plane
  • Dedicated CPU: Dedicated 8 GB Plan, 4 CPUs, 160 GB Storage

Download the kubeconfig.

# Update the KUBECONFIG env to gain access to the cluster
export KUBECONFIG=<path-to-downloads>/otomi--kubeconfig.yaml

Configure DNS​

AlERT

Support for Linode DNS is coming soon!

If you want to learn about how to use Linode DNS Manager read the following tutorials:

An Introduction to Managing DNS, and general documentation

Creating Linode Credentials​

Generate a new oauth token by following the instructions at Access-and-Authentication

Set environment variable for the token:

LINODE_TOKEN="<your-token-here>"

The environment variable LINODE_TOKEN will be needed to run ExternalDNS with Linode.

Create the values.yaml file​

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: linode
  domainSuffix: linode.example.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - example.com
  provider:
    linode:
      apiToken: $LINODE_TOKEN
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@example.com
EOF

And adjust the domainSuffix, domainFilters and email.

Install Otomi using helm​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- + \ No newline at end of file diff --git a/docs/get-started/installation/minikube/index.html b/docs/get-started/installation/minikube/index.html index 5ec241a1f..b325f582e 100644 --- a/docs/get-started/installation/minikube/index.html +++ b/docs/get-started/installation/minikube/index.html @@ -14,14 +14,14 @@ - +

Install Otomi on Minikube

ATTENTION

Otomi does NOT support ARM architecture and therefor can not be installed on Apple MacBook with Apple M1 chipset

NOTE

The installation examples below install Otomi without DNS.

Prerequisites​

  • minikube (Mac/Windows/Linux)
  • Linux only: kvm2 or Docker - detailed setup depends on Linux distribution

Configure Minikube cluster​

NOTE: Windows users, open PowerShell as Administrator to execute the commands

NOTE: Enable calico if you want to check network policies

For Windows​

minikube start --memory=8192 --cpus=8 --driver=hyperv --kubernetes-version=v1.26.9 --cni calico

For Mac​

minikube start --memory=8192 --cpus=8 --driver=hyperkit --kubernetes-version=v1.26.9 --cni calico

For Linux, using the KVM2 driver​

minikube start --memory=8192 --cpus=8 --driver=kvm2 --kubernetes-version=v1.26.9 --cni calico

Enable Metallb (Network Load Balancer)​

Non Interactive way:​

Copy and paste the following script into your terminal.

minikube addons enable metallb
MINIKUBE_IP=$(minikube ip);START_IP=101;END_IP=121
expect << _EOF_
spawn minikube addons configure metallb
expect "Enter Load Balancer Start IP:" { send "${MINIKUBE_IP%.*}.$START_IP\\r" }
expect "Enter Load Balancer End IP:" { send "${MINIKUBE_IP%.*}.$END_IP\\r" }
expect eof
_EOF_

If the above script fails, follow the steps described below in order to manually enable and configure Metallb addon, otherwise you can skip to the Install Otomi using helm Part

Manual Steps:​

Expand...

1.Manually Enable and Configure Metallb​

minikube addons enable metallb

2.Get the IP​

minikube ip

Terminal Output

192.168.49.2

Please note that IP might and will probably be different in your system

3.Configure metallb​

minikube addons configure metallb

Terminal Output

-- Enter Load Balancer Start IP: 192.168.49.101
-- Enter Load Balancer END IP: 192.168.49.121

Define the load balancer's IP address range using the above example replacing the IP address which is acquired in Step 3. Note First 3 segments of the IP should be same as the minikube IP Network address while the last segment may be customized.

Install Otomi using helm​

Add the Otomi repo​

helm repo add otomi https://otomi.io/otomi-core
helm repo update

Otomi install with minimal chart values​

helm install otomi otomi/otomi --set cluster.name=minikube --set cluster.provider=custom --set apps.host-mods.enabled=false --set apps.metrics-server.extraArgs.kubelet-insecure-tls=true --set apps.metrics-server.extraArgs.kubelet-preferred-address-types=InternalIP

The helm chart deploys an installer job responsible for installing the Otomi platform on the minikube cluster.

Monitor the job status​

kubectl get job otomi -w

Installer job logs​

kubectl logs jobs/otomi -n default -f

At the end of the logs of the installer job, you will find the URL and the credentials to log into the Otomi console.

Now follow the activation instructions here.

Additional resources​

- + \ No newline at end of file diff --git a/docs/get-started/installation/oidc/index.html b/docs/get-started/installation/oidc/index.html index 7ca9659bd..a030fa15f 100644 --- a/docs/get-started/installation/oidc/index.html +++ b/docs/get-started/installation/oidc/index.html @@ -14,13 +14,13 @@ - +

Azure AD for OIDC

The authentication of brokered identities through Azure AD requires a service principal with certain Azure AD API permissions. An app registration needs to be created with the following API permissions:

API / Permission nameTypeDescription
Microsoft Graph / emailDelegatedView users' email address
Microsoft Graph / openidDelegatedSign users in
Microsoft Graph / profileDelegatedView users' basic profile
Microsoft Graph / User.ReadDelegatedSign in and read user profile

And the following token configurations:

ClaimDescriptionToken typeOptional settings
family_nameProvides the last name, surename, or family nameID-
given_nameProvides the first or "give" name of the userID-
groupsOptional formatting for group claimsID, Access, SAMLDefault
upnAn identifier for the user that can be used ...IDDefault

Note that the group type should be set to 'security groups'.

At the 'Authentication' tab you should be able to set the following callback URL§s and enable that both "Access tokens" and "ID tokens" are issued and public client flows are allowed:

  • https://keycloak.<dns-zone-name>/realms/master/broker/otomi-idp/endpoint
  • https://keycloak.<dns-zone-name>

To install Otomi with Azure Active Directory as an IdP instead of (default) using Keycloak as an IdP, use the following values:

oidc:
  clientID: ""
  clientSecret: ""
  issuer: ""
  # IDP group id used to identify global admin
  adminGroupID: ""
  # IDP group id used to identify team admin
  teamAdminGroupID: ""
note

otomi-idp is the default KeyCloak alias (shown as login title). To use another alias, add the following to the chart values:

apps:
  keycloak:
    idp:
      alias: <your-alias>
- + \ No newline at end of file diff --git a/docs/get-started/installation/overview/index.html b/docs/get-started/installation/overview/index.html index d0bad35bb..90fa2fe26 100644 --- a/docs/get-started/installation/overview/index.html +++ b/docs/get-started/installation/overview/index.html @@ -14,13 +14,13 @@ - +

Installation

How to install Otomi on various cloud and infrastructure platforms

AWS​

Install Otomi on EKS using Route53 for DNS

Azure​

Install Otomi on AKS using an Azure public DNS zone

Civo​

Install Otomi on Civo K3s using Civo DNS

Custom​

Install Otomi on any other cloud or infrastructure platforms

Digital Ocean​

Install Otomi on Digital Ocean using Digital Ocean DNS

Google Cloud Platform​

Instal Otomi on GKE with Cloud DNS

Linode​

Install Otomi on Linode Kubernetes Engine using Linode DNS

Scaleway​

Install Otomi on Kapsule Kubernetes in Scaleway using a Scaleway Internal Domain

Vultr​

Install Otomi on Vultr Kubernetes using Cloudflare DNS

Other installation resources

Helm​

Instructions for using the Otomi Helm chart

Know issues​

Know installation issues

Advanced configurations

Use Azure AD as IDP​

Install Otomi with Azure AD for OIDC

Use KMS to manage keys for encryption​

Install Otomi with KMS

Configure an entrypoint for an external gateway​

Install Otomi with an entrypoint for an external gateway

Bring Your Own Wild Card Certificate​

Install Otomi using a BYO wild card certificate

- + \ No newline at end of file diff --git a/docs/get-started/installation/scaleway/index.html b/docs/get-started/installation/scaleway/index.html index 8888edbdd..e0006b16d 100644 --- a/docs/get-started/installation/scaleway/index.html +++ b/docs/get-started/installation/scaleway/index.html @@ -14,14 +14,14 @@ - +

Install Otomi on Scaleway Kubernetes Kapsule with Scaleway DNS

Prerequisites​

Create a Kubernetes Kapsule cluster​

Set the Project ID variable:

SCW_DEFAULT_PROJECT_ID=""

And run the following commands:

SCALEWAY_CLUSTER_NAME="otomi"
SCALEWAY_NODE_TYPE="PRO2-M"
SCALEWAY_NODE_POOL_MIN_SIZE=3
SCALEWAY_K8s_VERSION="1.27.6"
SCALEWAY_PRIVATE_NETWORK_ID=$(scw vpc private-network create project-id=$SCW_DEFAULT_PROJECT_ID name=$SCALEWAY_CLUSTER_NAME-pn region=nl-ams -ojson | jq -r .id)
scw k8s cluster create name=$SCALEWAY_CLUSTER_NAME \
    project-id=$SCW_DEFAULT_PROJECT_ID \
    private-network-id=$SCALEWAY_PRIVATE_NETWORK_ID \
    auto-upgrade.enable=false \
    cni=calico \
    pools.0.node-type=$SCALEWAY_NODE_TYPE \
    pools.0.min-size=$SCALEWAY_NODE_POOL_MIN_SIZE \
    pools.0.size=$SCALEWAY_NODE_POOL_MIN_SIZE \
    pools.0.max-size=3 \
    pools.0.autohealing=true \
    pools.0.autoscaling=true \
    pools.0.name=$SCALEWAY_CLUSTER_NAME \
    pools.0.root-volume-size=50GB \
    version=$SCALEWAY_K8s_VERSION \
    region=nl-ams

Configure DNS​

AlERT

Support for Scaleway DNS is coming soon!

Importing a Domain into Scaleway DNS​

In order to use your domain, you need to import it into Scaleway DNS. If it's not already done, you can follow this documentation

Once the domain is imported you can either use the root zone, or create a subzone to use.

In this example we will use example.com as an example.

Creating Scaleway Credentials​

To use Otomi with Scaleway DNS, you need to create an API token (composed of the Access Key and the Secret Key). You can either use existing ones or you can create a new token, as explained in How to generate an API token or directly by going to the credentials page.

Add the Access ans Secret key's to your environment variables:

SCW_ACCESS_KEY="<your-access-key>"
SCW_SECRET_KEY="your-secret-key"

Create the values.yaml file​

tee values.yaml<<EOF
cluster:
  name: otomi
  provider: scaleway
  domainSuffix: your-sub-domain.example.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters: 
    - example.com
  provider:
    scaleway:
      scwAccessKey: $SCW_ACCESS_KEY
      scwSecretKey: $SCW_SECRET_KEY
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@example.com
EOF

And adjust the domainSuffix, domainFilters and email based on your domain.

Install Otomi​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- + \ No newline at end of file diff --git a/docs/get-started/installation/vultr/index.html b/docs/get-started/installation/vultr/index.html index 1ee10425e..4bb055cd0 100644 --- a/docs/get-started/installation/vultr/index.html +++ b/docs/get-started/installation/vultr/index.html @@ -14,13 +14,13 @@ - +

Install Otomi on Vultr

Prerequisites​

Export your Vultr API Key:

export VULTR_API_KEY=<your api key>

Create a Kubernetes cluster​

vultr-cli kubernetes create \
    --label="otomi" \
    --region="ams" \
    --version="v1.27.7+1" \
    --node-pools="quantity:3,plan:vc2-4c-8gb,label:otomipool"

Configure DNS using Cloudflare​

Because DNS support for Vultr is not available in Otomi yet, we'll use Cloudflare DNS.

Creating a Cloudflare DNS zone​

We highly recommend to read this tutorial if you haven't used Cloudflare before:

Create a Cloudflare account and add a website

Creating Cloudflare Credentials​

Snippet from Cloudflare - Getting Started:

Cloudflare's API exposes the entire Cloudflare infrastructure via a standardized programmatic interface. Using Cloudflare's API, you can do just about anything you can do on cloudflare.com via the customer dashboard.

The Cloudflare API is a RESTful API based on HTTPS requests and JSON responses. If you are registered with Cloudflare, you can obtain your API key from the bottom of the "My Account" page, found here: Go to My account.

When using API Token authentication, the token should be granted Zone Read, DNS Edit privileges, and access to All zones.

If you would like to further restrict the API permissions to a specific zone (or zones), you also need to use the --zone-id-filter so that the underlying API requests only access the zones that you explicitly specify, as opposed to accessing all zones.

Set the CF_API_TOKEN environment variable:

CF_API_TOKEN="Your Cloudflare API Token"

Create the values.yaml file​

cluster:
  name: otomi
  provider: vultr
  domainSuffix: linode.example.com
otomi:
  hasExternalDNS: true
dns:
  domainFilters:
    - example.com
  provider:
    cloudflare:
      apiToken: $CF_API_TOKEN
      proxied: false
apps:
  cert-manager:
    issuer: letsencrypt
    stage: production
    email: admin@example.com

Install Otomi using helm​

Install Otomi using Helm:

helm repo add otomi https://otomi.io/otomi-core
helm repo update
helm install -f values.yaml otomi otomi/otomi

Monitor the logs of the installer job:

kubectl logs jobs/otomi -n default -f

When the installer is finished, copy the url and admin-password from the console output.

Follow the activation steps here.

tip

Like to learn how to use Otomi? Go through the Get Started labs

- + \ No newline at end of file diff --git a/docs/get-started/labs/deploy-workloads-argo-cd-otomi-kubernetes/index.html b/docs/get-started/labs/deploy-workloads-argo-cd-otomi-kubernetes/index.html index 46e9ff405..3ab4e8658 100644 --- a/docs/get-started/labs/deploy-workloads-argo-cd-otomi-kubernetes/index.html +++ b/docs/get-started/labs/deploy-workloads-argo-cd-otomi-kubernetes/index.html @@ -14,13 +14,13 @@ - +

Using Argo CD

Creating Kubernetes resources using kubectl apply -f can be inefficient. As a developer, managing resources based on code stored in Git enhances control and traceability. Otomi integrates with Argo CD to provide a seamless GitOps experience, streamlining your deployment process.

Create Kubernetes resources with Argo CD​

Start by navigating to the apps section in the Otomi console, where you will find an app named Argo CD. Click on it to proceed.

Argo CD App in Otomi Console

In Argo CD, notice that an application specific to your team has already been set up. This application syncs with any manifest present in the Gitea repository designated for your team.

Argo CD Team Application Overview

After clicking on the app and selecting APP DETAILS, you'll find the REPO URL.

Return to the Otomi console, select the Gitea app in the apps section. In Gitea you will see a repository titled otomi/team-<name>-argocd.

Gitea Repository for Argo CD in Otomi

See the Power of Argo CD in action​

Let's demonstrate the capabilities of Argo CD by adding some manifests to the repository:

  1. Create a file named deploy-nginx.yaml in the repository.

  2. Insert the following contents into the file:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nginx
      labels:
        otomi.io/app: nginx
        app: nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - name: nginx
              image: nginxinc/nginx-unprivileged:stable
              resources:
                limits:
                  memory: '128Mi'
                  cpu: '200m'
                requests:
                  memory: '64Mi'
                  cpu: '100m'
              ports:
                - containerPort: 8080
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: nginx
    spec:
      selector:
        app: nginx
      ports:
        - port: 80
          targetPort: 8080

  3. Commit the changes to the repository.

Once you return to the Argo CD application, click on the team<name> application.

The application is configured for automatic syncing, so a manual SYNC is not needed.

Syncing in ArgoCD

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-1/index.html b/docs/get-started/labs/lab-1/index.html index a2c8d6b73..70af5a12b 100644 --- a/docs/get-started/labs/lab-1/index.html +++ b/docs/get-started/labs/lab-1/index.html @@ -14,13 +14,13 @@ - +

Prerequisites for getting started

Welcome to Otomi! If you would like to explore Otomi, this getting started guide is for you.

Prerequisites​

We assume you (or the platform administrator) have:

  1. Installed Otomi with DNS configured. See here

  2. Activated the following applications:

  • Harbor
  • Prometheus
  • Loki
  • Grafana
  • Trivy Operator
  • Gatekeeper (with option Disable validating webhook set to true)

For the Use OpenTelemery Lab, the Tempo app needs to be enabled together with tracing in the Istio and Nginx Ingress apps.

  1. Created a team called labs with Grafana, Prometheus and Alertmanager activated
  2. Created an account and added your account to the labs team group in Keycloak. In the labs we'll be using the user labs-user
  3. Provided you with the following information:
  • The URL to access the Otomi web UI (Otomi Console)
  • Your login credentials

When you have received the URL of the web UI and have a username/password, then it's time to sign-in.

Sign in to the Console​

  • Go to the provided URL. The URL will look like this: https://otomi.yourdomain.com
  • Sign in with the provided username/password or your existing corporate AD account

After sign in, you will see this page:

Team apps

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-11/index.html b/docs/get-started/labs/lab-11/index.html index e52fd4873..25ecdcc03 100644 --- a/docs/get-started/labs/lab-11/index.html +++ b/docs/get-started/labs/lab-11/index.html @@ -14,13 +14,13 @@ - +

Configure auto image updater

When using the Workload feature in Otomi to deploy Helm charts from the Developer Catalog, then you can also use the Auto image updater feature to to automatically update the container images of Kubernetes workloads.

info

Otomi only supports the image update feature in combination with a Helm chart stored in the Developer Catalog.

Create a Workload with auto image updater​

Before creating a workload from the developer catalog, we'll need the repository and tag of the image we like to deploy. Go to the list of Builds and add the repository of the green build to your clipboard. Remember that the tag is latest.

You can now create a workload from the developer catalog:

  1. Go to Workloads in the left menu and click on New Workload
  2. Add the Name green for the workload
  3. Select otomi-quickstart-k8s-deployment from the catalog
  4. Set the Auto image updater to Digest and fill in the ImageRepository from the clipboard.

Digest is the update strategy and will update the image to the most recent pushed version of a given tag.

  1. In the workload values, change the following parameters:
image:
  repository: <paste from clipboard>
  tag: latest
  1. Click Submit

Now click on Deploy Changes

In the example above, we used the Digest update strategy. The Semver strategy allows you to track & update images which use tags that follow the semantic versioning scheme.

Expose the service​

Now go to the Expose services lab and expose the green service. When the service is created, go to Services in the left menu and click on the Url of the green service. What do you see?

Make code change to trigger a new build​

In the Trigger Builds lab we already created a Build called green and configured it with a trigger.

Now go to the green repo in Gitea and change the the welcome message:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Sample Deployment</title>
    <style>
      body {
        color: #ffffff;
        background-color: green
        font-family: Arial, sans-serif;
        font-size: 14px;
      }

      h1 {
        font-size: 500%;
        font-weight: normal;
        margin-bottom: 0;
      }

      h2 {
        font-size: 200%;
        font-weight: normal;
        margin-bottom: 0;
      }
    </style>
  </head>
  <body>
    <div align="center">
      <h1>Welcome to the improved Green app</h1>
    </div>
  </body>
</html>

And commit changes.

After the change has been committed, go to Services in the left menu and click on the Url of the green service. After a couple of minutes (note that the auto image update checks for changes every 2 minutes) you should see a green page saying Welcome to the improved Green app

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-12/index.html b/docs/get-started/labs/lab-12/index.html index 2535857d0..381d6bf29 100644 --- a/docs/get-started/labs/lab-12/index.html +++ b/docs/get-started/labs/lab-12/index.html @@ -14,13 +14,13 @@ - +

Deploy a BYO Helm chart

Otomi offers a self-service feature to create 3 types of workloads:

In this Lab you're going to create a workload in Otomi to install your're own Helm chart and we'll be using the Otomi demo Hello World Nodejs Helm chart.

Creating a Workload to install your Helm chart​

  • Click on Workloads in the left menu.
  • Click on Create Workload

kubecfg

  • Select Bring your own Helm chart

kubecfg

  • Enter the following name for the workload

hello-world

  • Enter the URL to the Git repo containing the Helm chart or a Helm repository

https://github.com/redkubes/nodejs-helloworld

  • Add the Path of the chart within the repo:

chart/hello-world

kubecfg

  • Click Next
  • We are going to use the default chart values, so there is no need to fill in any values here
  • Click Submit

The values of a workload can be changed at any time. Changes will automatically be deployed.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-13/index.html b/docs/get-started/labs/lab-13/index.html index 59280a3aa..12edba14a 100644 --- a/docs/get-started/labs/lab-13/index.html +++ b/docs/get-started/labs/lab-13/index.html @@ -14,13 +14,13 @@ - +

Deploy workloads using Otomi

In the previous lab we deployed a workload using Argo CD with a BYO manifest and we explored the Catalog. In this lab we'll create a workload (a Kubernetes Deployment) using the Catalog and the Workload feature.

Create a Workload from the Catalog​

Before creating a workload from the Catalog, we'll need the repository and tag of the image to use. Go to the list of Builds and add the repository of the blue build to your clipboard. Remember that the tag is latest.

You can create a workload from the developer catalog:

  1. Go to Catalog in the left menu and click on the k8s-deploymenttemplate
  2. Click on Values
  3. Add the Name blue
  4. Leave the Auto image updater to Disabled
  5. In the workload values, change the following parameters:
image:
  repository: <paste from clipboard>
  tag: latest

workloads

  1. Click Submit and then Deploy Changes

Otomi will now create all the needed Argo CD resources to deploy your workload.

  1. Click on Workloads in the left menu. You will now see a list of all Workloads and there status:

workloads

  1. In the workloads list, click on the Application link of your workload to see the status of your workload in Argo CD:

workloads

The values of a workload can be changed at any time. Changes will automatically be synchronized.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-14/index.html b/docs/get-started/labs/lab-14/index.html index 8e0d0c5a0..3a76dc367 100644 --- a/docs/get-started/labs/lab-14/index.html +++ b/docs/get-started/labs/lab-14/index.html @@ -14,13 +14,13 @@ - +

Deploy serverless workloads

info

Prerequisite: For this lab, Argo CD needs to be activated.

Otomi uses Knative serving for serverless (or Function as a Service) support.

As a developer, you'll have the following options to deploy serverless workloads:

  • BYO Knative service manifest and deploy it using kubectl or ArgoCD
  • Create workloads with the deployment Helm chart in otomi-charts
  • Create workloads with the Knative Helm chart in otomi-charts

In this lab we're going to create a workload in Otomi to create a Knative service using the knative chart in otomi-charts.

Create a Function as a Service workload​

You can create a workload to deploy your own Helm chart, or you can use one of the otomi-charts Helm charts. In this case we'll use the deployment chart in the otomi-charts repository.

  1. Go to Workloads in the left menu and click on New Workload
  2. Choose Function as a Service

kubecfg

  1. Enter a name for the workload
hello-ksvc
  1. Fill in the image to deploy:
otomi/nodejs-helloworld
  1. Fill in the tag of the image to deploy:
v1.2.13

kubecfg

info

Note: When creating a Function as a Service workload, the Min Instances will by default be set to 0 to enable Scale to Zero.

  1. Click Next
  2. Review the values. Here you can add more values supported by the otomi-charts

kubecfg

  1. Click Submit

Now click on Deploy Changes

After a few minutes, Otomi will have created all the needed Argo CD resources to deploy your workload. In the workloads list, click on the Application link of your workload to see the status of your workload.

The values of a workload can be changed at any time. Changes will automatically be deployed.

(optionally) Publicly expose the service​

  • In the left menu panel under click Services then click on Create Service
  • Select the name of the (existing) knative service: hello-ksvc
  • Under Exposure Ingress, select Ingress and use the default configuration
  • Click on Submit
  • Click on Deploy Changes (the Deploy Changes button in the left panel will light-up after you click on submit).
- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-15/index.html b/docs/get-started/labs/lab-15/index.html index e888e3332..67c80df8a 100644 --- a/docs/get-started/labs/lab-15/index.html +++ b/docs/get-started/labs/lab-15/index.html @@ -14,13 +14,13 @@ - +

Check policy compliance

info

Prerequisite: For this lab, Gatekeeper needs to be activated.

When the platform administrator has enabled Gatekeeper and configured policies, you might like to check and see if your workloads are policy compliant. When the administrator has enabled Gatekeeper on the platform level, each team will automatically get access to a Policy Violations dashboard in Grafana.

View policy violations​

  • Open the Grafana app
  • Click on Dashboards / Browse
  • In the list of dashboards you will see a dashboard called Policy Violations. Click on it
  • Now you will see the following dashboard, showing all detected policy violations within your team workloads

policy-violations

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-16/index.html b/docs/get-started/labs/lab-16/index.html index ec5a7de5a..4d155df8e 100644 --- a/docs/get-started/labs/lab-16/index.html +++ b/docs/get-started/labs/lab-16/index.html @@ -14,13 +14,13 @@ - +

Check for threads

info

Prerequisite: For this lab, Falco needs to be activated.

When the platform administrator has enabled Falco, you might like to check and see if any threads are detected in your workloads. When the administrator has enabled Falco on the platform level, each team will automatically get access to a Detected threads dashboard in Grafana.

View detected threads​

  • Open the Grafana app
  • Click on Dashboards / Browse
  • In the list of dashboards you will see a dashboard called Detected Threads. Click on it
  • Now you will see the following dashboard, showing all the detected threads in your team workloads

detected-threads

To learn more about the detection rules, see the complete list of all the rules here.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-17/index.html b/docs/get-started/labs/lab-17/index.html index 695f42d99..7a6662649 100644 --- a/docs/get-started/labs/lab-17/index.html +++ b/docs/get-started/labs/lab-17/index.html @@ -14,13 +14,13 @@ - +

Scan your running containers for vulnerabilities

info

Trivy need to be activated for this lab.

So now you know how to scan container images when pushed to Harbor. But what if you have long running versions of containers? When new vulnerabilities are identified after you scanned the image, you wil only see them when you update your image. For this scenario, Otomi offers Trivy Operator for automatic daily scanning of containers in all Teams.

See Trivy scan results​

When Trivy is enabled by the platform admin and Otomi runs in multi-tenant mode, then each team will see the Trivy scan results for all containers deployed within the Team, in a Trivy dashboard in Grafana.

  • In the left menu, click on apps
  • Click on Grafana
  • Open the Trivy scan results dashboard

In the dashboard you can see all identified vulnerabilities per container:

kubecfg

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-18/index.html b/docs/get-started/labs/lab-18/index.html index a1d64fe02..550103fcc 100644 --- a/docs/get-started/labs/lab-18/index.html +++ b/docs/get-started/labs/lab-18/index.html @@ -14,13 +14,13 @@ - +

Publicly expose workloads

When you have deployed your application using the Workloads feature, you will probably like to expose it publicly. In this lab we'll create a Service in Otomi to expose your application publicly. When you create a Service, Otomi will create the Istio virtual service and configure ingress for your application.

Create a Service​

  • In the left menu panel under click Services then click on Create Service

expose services

  • Select the blue service of the Workload we created in the previous lab:

expose services

  • Under Exposure Ingress, select Ingress and use the default configuration

expose services

  • Click Submit
  • Click Deploy Changes (the Deploy Changes button in the left panel will light-up after you click on submit).

Deploying changes in Otomi usually takes just a couple of minutes depending on the amount of resources available on your cluster. You will see your service in the list of Services. Click on the URL and see your application.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-19/index.html b/docs/get-started/labs/lab-19/index.html index 21fd00e26..bb0c5b949 100644 --- a/docs/get-started/labs/lab-19/index.html +++ b/docs/get-started/labs/lab-19/index.html @@ -14,13 +14,13 @@ - +

Configuring network policies

In some cases you want to explicitly allow access to your application. This can be done by creating network policies. Otomi supports 2 types of network policies:

  • Policies for ingress traffic inside the cluster
  • Policies for egress traffic to go outside of the cluster (to access external FQDNs)

About network policies for internal ingress​

The internal ingress network policies alllow you to:

  • Deny all traffic to the Pods of a Workload
  • Allow selected Workload Pods running on the cluster to access your Workload's Pods

Deny all and Allow all we don't need to explain right?

info

The Ingress Network Policies in Otomi rely on the otomi.io/app label. All Workloads in Otomi need to use this label. When your using an Otomi quick start template from the Catalog, this label is always added.

To allow other Workloads on the cluster to access your Workload's Pods, do the following:

If the ClusterIP service of your workload has the same name as the otomi.io/app label value:

  • Register the Kubernetes ClusterIP service of the Workload as a Service in Otomi. If no public ingress is required, then just use the Private Exposure option
  • In the Network policies section leave the PodSelector field blanc
  • In the Ingress traffic inside the cluster select Allow selected
  • Add the team name (without team-) and otomi.io/app label value of the Workload Pods that are allowed access

If the ClusterIP service of your workload does NOT have the same name as the otomi.io/app label value:

This is sometimes the case when a Workload has multiple ClusterIP services. In this scenario you will only need to configure the network policies in one of the Workload services.

  • Register the Kubernetes ClusterIP service of the Workload as a Service in Otomi. If no public ingress is required, then just use the Private Exposure option
  • In the Network policies section leave the PodSelector add the PodSelector. Use a custom value for the "otomi.io/app:" label.
  • In the Ingress traffic inside the cluster select Allow selected
  • Add the team name (without team-) and otomi.io/app label value of the Workload Pods that are allowed access

Configure network policies for the Example Voting App​

Building the images​

Build the Vote, Worker and Result images from this repo.

Use the Build feature in Otomi to build the images with mode-Docker. Set the path to ./vote/Dockerfile for the Vote image (and ./worker/Dockerfile for the Worker and ./result/Dockerfile for Result).

Create a Redis cluster and a PostgreSQL database​

Use the postgresql and the redis charts from the Catalog to create a Redis master-replica cluster and a PostgreSQL database. For this lab, Redis authentication needs to be turned off by setting auth.enabled=false.

Deploy the Vote app​

Use the k8s-deployment chart to deploy the vote app. Use the following values:

Name: vote

containerPorts:
  - name: http
    containerPort: 80
    protocol: TCP
env:
  - name: REDIS_HOST
    value: <redis-cluster-name>-master

Deploy the Worker app​

Use the k8s-deployment chart to deploy the worker app. Use the following values:

Name: worker

containerPorts:
  - name: http
    containerPort: 80
    protocol: TCP
env:
  - name: DATABASE_USER
    valueFrom:
      secretKeyRef:
        name: <psql-cluster-name>-superuser
        key: username
  - name: DATABASE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: <psql-cluster-name>-superuser
        key: password
  - name: REDIS_HOST
    value: <redis-cluster-name>-master
  - name: DATABASE_HOST
    value: <psql-cluster-name>-rw

Deploy the Result app​

Use the k8s-deployment chart to deploy the result app. Use the following values:

Name: result

containerPorts:
  - name: http
    containerPort: 80
    protocol: TCP
env:
  - name: DATABASE_USER
    valueFrom:
      secretKeyRef:
        name: <psql-cluster-name>-superuser
        key: username
  - name: DATABASE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: <psql-cluster-name>-superuser
        key: password
  - name: DATABASE_HOST
    value: <psql-cluster-name>-rw

Register the services for Exposure and configure network policies​

Postgres database​

  • Register the <workload-name>-rw Postgresql service
  • Set exposure to Private (default)
  • In Network policies add the Pod Selector <postgres-workload-name>
  • Select Allow selected
  • Add From team name <team-name> and From label value <postgres-workload-name>
  • Add From team name <team-name> and From label value <worker>
  • Add From team name <team-name> and From label value <result>

Redis​

  • Register the <workload-name>-master Redis service
  • Set exposure to Private (default)
  • In Network policies add the Pod Selector <redis-workload-name>
  • Select Allow selected
  • Add From team name <team-name> and From label value <redis-workload-name>
  • Add From team name <team-name> and From label value <worker>
  • Add From team name <team-name> and From label value <vote>

Vote​

  • Register the vote service
  • Set exposure to External

Result​

  • Register the <result> service
  • Set exposure to External

Test the app​

Go to the external URL of the vote application. Click on Cats or Dogs. Now go to the external URL of the result application. You should see the result of your vote.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-2/index.html b/docs/get-started/labs/lab-2/index.html index bf49d2e15..902d9f10d 100644 --- a/docs/get-started/labs/lab-2/index.html +++ b/docs/get-started/labs/lab-2/index.html @@ -14,13 +14,13 @@ - +

Access Otomi Console and download the KUBECFG

When you have received the URL of the web UI of Otomi Platform and have a username/password with access permissions, then it's time to sign-in

Sign in​

  • Go to the provided URL. The URL will look like this: https://otomi.yourdomain.com
  • Sign in with the provided username/password or your existing corporate AD account

After sign in, you will see this page:

Team apps

(Optional) Download CA​

In some cases the platform is using a non-trusted CA. In this case you can download the CA and add it to your keychain.

info

When Otomi is using non-trusted certificates (and is probably not configured with DNS), you will not be able to do the labs that are using Harbor.

  • In the left menu of the console, click on "Download CA"

kubecfg

  • Double click the downloaded CA.crt or add the CA to your keychain on Mac using the following command:
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/Downloads/ca.crt

On Windows, use PowerShell (running as Administrator) with the Certutil:

certutil.exe -addstore root <downloaded cert path>

Or:

Import-Certificate -FilePath "<downloaded cert path>" -CertStoreLocation Cert:\LocalMachine\Root
# Restart the browser

But you could also run Chrome in insecure mode:

alias chrome-insecure='/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors --ignore-urlfetcher-cert-requests &> /dev/null'
- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-20/index.html b/docs/get-started/labs/lab-20/index.html index ec2bfedce..b62ed2299 100644 --- a/docs/get-started/labs/lab-20/index.html +++ b/docs/get-started/labs/lab-20/index.html @@ -14,13 +14,13 @@ - +

View container logs

info

Loki, Minio, Prometheus and Grafana need to be activated for this lab.

When your application is deployed, you would of course like to be able to see container logs for debugging purposes. Grafana Loki is used in Otomi for log aggregation. When Grafana Loki is enabled, you'll see the Loki app in your apps.

info

Only when Otomi is configured in multi-tenant mode, container logs of teams are split up between teams. This means you can only see the logs of your own team. If multi-tenancy is not enabled, you can see the logs of all containers running on the cluster. If you don't want other teams to see your logs, ask the administrator to enable the Otomi multi-tenancy feature.

View container logs​

  • Open the Loki app in your team apps

kubecfg

In Grafana, you are directed to the Explore section. Otomi already added a query for you, showing the logs of all containers running in your team namespace.

kubecfg

Select the label app and then select blue. You will now see all the blue container logs. You can also create your own queries. Learn more about LogQL here.

Creating shortcuts​

When you created a custom query that you would like to use more often, or would like to share with the team, you can create a shortcut in Otomi.

  • Copy the absolute path of your query
  • In the apps section, click on the Settings icon of the Loki app
  • Click on the Shortcuts tab
  • Click edit
  • Click on Edd item
  • Fill in the Title, Description and the Path for the shortcut

kubecfg

  • Click submit and then click Deploy Changes

Now click on the Shortcuts item in the left menu. Your shortcut is now available for everyone in the team to use.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-21/index.html b/docs/get-started/labs/lab-21/index.html index 0faa9e6e6..89aaeb881 100644 --- a/docs/get-started/labs/lab-21/index.html +++ b/docs/get-started/labs/lab-21/index.html @@ -14,13 +14,13 @@ - +

View container metrics

info

Prometheus and Grafana for the Team need to be activated for this lab.

When your application is deployed, you would of course like to be able to see container metrics for debugging purposes. Prometheus is used in Otomi for metrics. When Prometheus is enabled, you'll see the Prometheus app in your apps.

info

When Grafana, Prometheus and Alertmanger are enabled for the Team, the team will get it's own instance of Grafana, Prometheus and/or Alertmanager. Container metrics are provided by the platform Prometheus and you can use the Team's Prometheus to collect custom application metrics.

View dashboards​

  • Open the Grafana app in your team apps

kubecfg

  • Grafana will open the Dashboards page:

kubecfg

The dashboards are dynamically added based on the enabled platform capabilities:

DashboardWhen added
Kubernetes / DeploymentWhen Prometheus on platform level is enabled
Kubernetes / PodsWhen Prometheus on platform level is enabled
Team statusWhen Prometheus on platform level is enabled
Container scan resultsWhen Trivy on platform level is enabled
Policy violationsWhen Gatekeeper on platform level is enabled
Detected threads in containersWhen Falco on platform level is enabled

View container metrics​

  • Click on the Kubernetes / Pods dashboard
  • Select the required Pod and Container
- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-22/index.html b/docs/get-started/labs/lab-22/index.html index e0017e129..d95134896 100644 --- a/docs/get-started/labs/lab-22/index.html +++ b/docs/get-started/labs/lab-22/index.html @@ -14,13 +14,13 @@ - +

Using custom metrics

What are custom metrics​

Prometheus will collect all kind of standard container metrics like CPU and memory usage, but no (custom) business or customer metrics like the number of customers who logged into your app each hour.

To be able to collect custom metrics you will need to expose this data in your code. This is called instrumentation of code and can include annotating the code with metadata, or adding in logic to calculate and expose data.

Instrumenting code means you write code to expose information about the technical, business, and customer context. This information can then be collected and analyzed using Prometheus and Grafana.

In this lab we'll not dive into the way how to instrument your code. We will use a container that exposes custom metrics and then show how the metrics can be collected and analysed.

Create a Workload​

  1. Go to the Catalog and click on the k8s-deployment template

  2. Click on the Values tab

  3. Fill in the name custom-metrics

  4. Use the following values:

image:
  repository: quay.io/rbaumgar/monitor-demo-app-jvm
  pullPolicy: IfNotPresent
  tag: latest
containerPorts:
  - name: web
    containerPort: 8080
    protocol: TCP
servicePorts:
  - port: 8080
    targetPort: 8080
    protocol: TCP
    name: web
replicaCount: 2
serviceMonitor:
  create: true
  endpoints:
    - interval: 30s
      port: web
      scheme: http
      path: /q/metrics
  1. Click Submit and then Deploy Changes

Check the status of the ServiceMonitor​

Check if the ServiveMonitor has been picked up by Prometheus:

  1. In the left menu go to Apps
  2. Click on the Prometheus app
  3. In Prometheus, click on Status in the top menu and then click Targets
  4. You will now see that the ServiceMonitor has the State UP:

metrics

Okay, our metrics are now being scraped by the Team's Prometheus. Before we continue, let's first generate some load:

  1. Go to the Expose services lab and expose the custom-metrics service

  2. Run the following command in your terminal:

for i in {1..1000}; do curl https://custom-metrics-labs.<your-domain>/hello; sleep 10; done
  1. Wait for approximately 10 minutes...

See the custom metrics​

To see the metrics:

  1. Open the Prometheus app
  2. In Prometheus, fill in the following Expression: application_greetings_total
  3. Click on Graph
  4. You should now see the following:

metrics

Next steps​

Prometheus is now scraping our custom metrics. You can now use these metrics to:

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-23/index.html b/docs/get-started/labs/lab-23/index.html index fb6144090..3a2f7dedb 100644 --- a/docs/get-started/labs/lab-23/index.html +++ b/docs/get-started/labs/lab-23/index.html @@ -14,13 +14,13 @@ - +

Monitoring service availability

When your application is deployed, you would of course like to get an alert when you application (service) is not available anymore. To automatically monitor you applications for availability, Otomi automatically configures a prope to monitor your service.

Monitor your application for availability​

  1. Create a Service for your app in Otomi. The service can have an Exposure ingress of type Cluster or Ingress

  2. Open Prometheus

kubecfg

  1. In Prometheus, Go to Status and click on Targets

kubecfg

In the list of targets you will see:

  • The PodMonitor endpoints of the istio sidecars os the Team Workloads
  • The Probes of all the Team services that are exposed
  1. In Prometheus, Go to Alerts

kubecfg

In the alerts you will see an (inactive) alert for ProbeFailing. If the State of a Servive Probe is Down the Prometheus Rule for this alert will fire. When alertmanager is enabled, and an alert notification receiver is configured, you will automatically receive an alert when your exposed Service is down.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-24/index.html b/docs/get-started/labs/lab-24/index.html index 2dd22fb6f..83a7ea8f7 100644 --- a/docs/get-started/labs/lab-24/index.html +++ b/docs/get-started/labs/lab-24/index.html @@ -14,13 +14,13 @@ - +

Create a PostgreSQL database

Otomi by default installs the Cloudnative POstgreSQL database operator. Teams can use the operator and the postgresql quick start to create their own PostgreSQL databases.

Create a database​

You can create a postgresql database from the developer catalog:

  1. Go to Catalog in the left menu and click on the postgresql template
  2. Click on Values
  3. Fill in a name for the database
  4. Change other parameter values as required
  5. Click Submit and the Deploy Changes

The operator will now create the database and add a secret to the team's namespace called <database-name>-superuser. This secret contains the username and password for the database with the keys username and password.

You can now provide the username and password to a container as environment variables using a secretKeyRef:

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: <database-name>-superuser
      key: password
- name: SECRET_KEY
  valueFrom:
    secretKeyRef:
      name: <database-name>-superuser
      key: username

Monitoring​

The postgresql quick start template includes two parameters that can be used to create a PodMonitor and a Grafana Dashboard. Set the monitoring parameter to true to create a PodMonitor and set the dashboard parameter to true to add a cloudnativepg dashboard to the Team's Grafana. Note that this dashboard can be used to monitor multiple databases so you'll just need to create it once.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-25/index.html b/docs/get-started/labs/lab-25/index.html index da7c8777c..339ca7488 100644 --- a/docs/get-started/labs/lab-25/index.html +++ b/docs/get-started/labs/lab-25/index.html @@ -14,13 +14,13 @@ - +

Monitor PostgreSQL databases

If you previously created a database, you'll noticed that we did not let the operator create a PodMonitor. The reason of this, is that the PodMonitor requires specific lables to be picked-up by the team's own Prometheus. In this lab we'll create a custom PodMonitor and create a dashboard in the team's own Grafana.

Create a PodMonitor​

  1. In the apps section in Otomi console, click on Gitea. In the list of repo's you'll now see a new repo called otomi/team-<name>-argocd.
  2. Create a new file called my-db-pod-monitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: my-db-pm
  labels:
    cnpg.io/cluster: my-db
    prometheus: team-demo
spec:
  namespaceSelector:
    matchNames:
      - team-demo
  podMetricsEndpoints:
    - port: metrics
  selector:
    matchLabels:
      cnpg.io/cluster: my-db
  1. Save the file and commit the changes.

The pod monitor will be picked-up by the team's own Prometheus. You can now add a dashboard to the team's Grafana instance.

Add a custom dashboard to the team's Grafana​

  1. Create a new file called my-db-dashboard.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-db-cluster-dashboard
  labels:
    grafana_dashboard: "1"
    release: grafana-dashboards-demo
data:
  cnp.json: |-
    # your dashboard json
- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-26/index.html b/docs/get-started/labs/lab-26/index.html index 53d53f9a1..747219670 100644 --- a/docs/get-started/labs/lab-26/index.html +++ b/docs/get-started/labs/lab-26/index.html @@ -14,13 +14,13 @@ - +

Trigger builds

In the previous lab we created a build in Otomi using the blue repo in Gitea. In this lab we'll create a build for the green repo and trigger the build based on a webhook.

Create a build in Otomi with Trigger enabled​

  1. In the left menu, click on Builds
  2. Click on Create Build
  3. Fill in the name green for your build
  4. Choose ./Dockerfile and fill in the repo URL for the green repo created in the previous lab.
  5. Enable Trigger
  6. Click Submit

Get the webhook URL​

Before we can configure the webhook for the green repo in Gitea, we will need the webhook URL. You can find this webhook URL for your build in the list of Builds. Add the webhook URL to your clipboard.

trigger build

Also notice that the status of the Build shows an exclamation mark. This is because Otomi created the Pipeline, but the PipelineRun is not yet created because it was not triggered yet.

Create a Webhook​

  1. In Otomi Console, click on apps the left menu and then open Gitea
  2. In the top menu of Gitea, click on Explore and then on the green repo
  3. Go to Settings (top right) and then to Webhooks
  4. Click Add Webhook and select Gitea
  5. In the Target URL, paste the webhook URL from your clipboard.
  6. Click Add Webhook

Trigger the build​

You can now trigger the build by doing a commit in the green repo, or by testing the webhook. Let's test the webhook:

  1. In Gitea, go to the Settings (top right) of the green repo and then to Webhooks
  2. Click on the webhook we just created
  3. In the bottom, click on Test Delivery

Check the status of the build​

The build should now have started. Based on the webhook, Tekton has now created a PipelineRun. Let's check the status of the PipelineRun:

  1. In Otomi Console, click on Builds

Because the Build was triggered, a PipelineRun is now running and the status of the Build will show in progress:

trigger build

When the Build is completed, the status will show healthy:

trigger build

  1. In the list of Builds, click on the PipelineRun link of the green build
  2. Tekton Dashboard will open and show a list of all the PipelineRuns. It will show all PipelineRuns because when using a Trigger, the PipelineRun resource is created based on a template and Otomi will not know the exact name of the PipelineRun because the name is automatically generated.
  3. Click on the PipelineRun with the name docker-trigger-build-green-*
  4. You can now see the the full log of the build
- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-27/index.html b/docs/get-started/labs/lab-27/index.html index ed11c3159..fe565a382 100644 --- a/docs/get-started/labs/lab-27/index.html +++ b/docs/get-started/labs/lab-27/index.html @@ -14,13 +14,13 @@ - +

OpenTelemetry

In order to make a system observable, it must be instrumented. Language specific implementation of OpenTelemetry provides a way to instrument your application without touching your source code. In this lab we're going to instrument a Java application.

Prerequisites​

For this lab it is required to:

  • Enable Tempo
  • Enable tracing for Istio and Nginx Ingress

Build an image from source code​

For this lab we're going to use the Spring PetClinic Sample Application. Follow these steps to build an image from source code:

note

Using a Gitea repository is not required. You can also build using public repositories.

  1. Create a new repo called petclinic
  2. Clone the Spring PetClinic Sample Application:
git clone https://github.com/spring-projects/spring-petclinic.git
cd spring-petclinic
  1. Mirror the Spring PetClinic Sample Application to your petclinc repo:
git push --mirror https://gitea.<your-domain>/<your-user-name>/petclinic.git
  1. Go to Builds in the left menu and click Create Build
  2. Fill in the Build name petclinic
  3. Choose Buildpacks
  4. Fill in the Repo URL with the petclinic Gitea repo you created
  5. Click Submit

Create a workload from the developer catalog​

Go to the list of Builds and add the repository of the petclinc build to your clipboard. Remember that the tag is latest.

  1. Go to Workloads in the left menu and click on New Workload
  2. Add the Name petclinic for the workload
  3. Select otomi-quickstart-k8s-deployment-otel from the catalog
  4. Leave the Auto image updater to Disabled
  5. In the workload values, change the following parameters:
image:
  repository: <paste from clipboard>
  tag: latest

Because we're deploying a Java application here, maybe also change the resources:

resources:
  limits:
    cpu: 500m
    memory: 1Gi
  requests:
    cpu: 300m
    memory: 256Mi
  1. Click Submit

Now click on Deploy Changes

Expose the service​

  • In the left menu panel under click Services then click on Create Service
  • Select the petclinic service
  • Under Exposure Ingress, select Ingress and use the default configuration
  • Click Submit
  • Click Deploy Changes

See traces​

To be able to see traces, we'll first need to generate some requests. Click on the URL of the petclinic service and generate some requests.

To see traces, you'll first need to find a TraceID of a trace. Go to Apps in the left menu and then click op Loki. Select the label App and select value petclinic.

Click on a log entry of a request. Note that the requests are logged by the Istio Envoy proxy. You will now see a link to the full trace in Grafana Tempo. Click on it.

note

If you don't see any traces, check and see if the pod runs the ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:1.26.0 container. Sometimes the pod starts before the Instrumentation resource has been created. If this is the case, restart the Pod

Team apps

And when you click on the Node graph, you’ll see the complete flow:

Team apps

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-28/index.html b/docs/get-started/labs/lab-28/index.html index f7dbc0a6f..76aa5ee67 100644 --- a/docs/get-started/labs/lab-28/index.html +++ b/docs/get-started/labs/lab-28/index.html @@ -14,13 +14,13 @@ - +

Canary deployments

In this lab we are going to create a canary deployment. The idea behind canary deployment (or rollout) is to introduce a new version of a service by first testing it using a small percentage of user traffic, and then if all goes well the percentage while simultaneously phasing out the old version.

For this we are going to deploy the stable version (blue), introduce a new version and then change the new version until we are happy with it and then increase the traffic to the new version.

Prepare images​

For this lab we need the 2 images (blue and green) we already created in the previous labs. If you haven't created the blue and green images, first complete these 2 labs:

Create a workload from the developer catalog​

Go to the list of Builds and add the repository of the green build to your clipboard.

  1. Go to Workloads in the left menu and click on New Workload
  2. Add the Name canary for the workload
  3. Select otomi-quickstart-k8s-deployment-canary from the catalog
  4. Set the Auto image updater to Digest and fill in:
  • imageRepository = paste from the clipboard
  • imageParameter = versionTwo.image.repository
  • tagParameter = versionTwo.image.tag
  1. In the workload values, change the following parameters:
# For the v1 as the stable version
versionOne:
  image:
    repository: # paste from clipboard, but change to blue
    tag: latest
# The v2 as canary with the auto image updater configured
versionTwo:
  image:
    repository: # paste from clipboard. This will be the green image
    tag: latest
  1. Click Submit

Now click on Deploy Changes

We now created 2 deployments. One for blue and one for green. The green image (our canary) will be automatically updated after a change (commit).

Expose the service​

  • In the left menu panel under click Services then click on Create Service
  • Select the canary service
  • Under Traffic Control click enabled (and use the default weights for v1 and v2)
  • Under Exposure Ingress, select Ingress and use the default configuration
  • Click Submit
  • Click Deploy Changes

See the results​

You will see the canary service in the list of Services. Click on the URL and refresh the page for a couple of times. You should first see:

Team apps

After a refresh of the page you should see:

Team apps

Update the canary image​

Go to the green repo and change the background-color in the green.html file from green to MediumSeaGreen and commit the change. After a couple of minutes you should now see the background color of version 1 (our canary) changed:

Team apps

Do you see the difference?

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-29/index.html b/docs/get-started/labs/lab-29/index.html index 0eb95fd23..cf711815d 100644 --- a/docs/get-started/labs/lab-29/index.html +++ b/docs/get-started/labs/lab-29/index.html @@ -14,13 +14,13 @@ - +

Explore the Catalog

In this lab we are going to explore the Catalog in Otomi. The Catalog is a library of curated Helm charts to create Kubernetes resources. By default the Catalog contains a set of Helm charts provided by Otomi to get started quickly, but they can also be modified depending on your requirements or be removed from the Catalog. The contents of the Catalog and the RBAC configuration (which Team can use which Helm chart) are managed by the platform administrator. Contact the platform administrator if you would like to add your own charts to use within your Team.

About Otomi Catalog quick starts​

The Catalog contains a set of Helm charts that can be used as quick starts. The following quick starts are available:

k8s-deployment​

The otomi-quickstart-k8s-deployment Helm chart can be used to create a Kubernetes Deployment (to deploy a single image), a Service and a ServiceAccount. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap can be created.

k8s-deployment-otel​

The otomi-quickstart-k8s-deployment-otel Helm chart can be used to create a Kubernetes Deployment (to deploy a single image), a Service, a ServiceAccount, an OpenTelemetryCollector and an Instrumentation. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap can be created.

k8s-deployments-canary​

The otomi-quickstart-k8s-deployments-canary Helm chart can be used to create 2 Kubernetes Deployments (to deploy 2 versions of an image), a Service and a ServiceAccount. Optionally a HorizontalPodAutoscaler, a Prometheus ServiceMonitor and a Configmap (for each version) can be created.

knative-service​

The otomi-quickstart-knative-service Helm chart can be used to create a Knative Service (to deploy a single image), a Service and a ServiceAccount. Optionally a Prometheus ServiceMonitor can be created.

Otomi quick start for creating a PostgreSQL cluster​

The otomi-quickstart-postgresql Helm chart can be used to create a cloudnativepg PostgreSQL Cluster. Optionally a Prometheus PodMonitor and a Configmap (for adding a postgresql dashboard to Grafana) can be created.

Otomi quick start for creating a Redis master-replica cluster​

The otomi-quickstart-redis Helm chart can be used to create a Redis master-replica cluster.

Using the Catalog​

  1. Click on Catalog in the left menu
  2. You will now see all the templates that are available to use

catalog

  1. Click on the k8s-deployment template

catalog

In the Info tab you'll see some information about the Chart like the version and additional instructions.

  1. Click on the Values tab

catalog

From here you can create a Workload using the Catalog template by adding a name and changing the values. Go to the next lab to create a workload.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-3/index.html b/docs/get-started/labs/lab-3/index.html index bfb3282b2..7b821b6e3 100644 --- a/docs/get-started/labs/lab-3/index.html +++ b/docs/get-started/labs/lab-3/index.html @@ -14,13 +14,13 @@ - +

Create a private Git repo

As a developer you'll need a Git repository for your code. Most organizations will probably have a central code repository like Gitlab, or use Github. But if you don't, Otomi has you covered. Otomi includes a complete self-hosted Git solution called Gitea.

As a team member, you can create and manage your own repositories.

info

Team members first have to sign in to Gitea (using OpenID), after which they are automatically added to the correct team.

info

The otomi-admin account is unable to login with OpenID, this account needs to login with the user/password login form.

In the labs we'll be using a Team called labs and a user called labs-user.

Using a Git client​

Gitea in Otomi only supports HTTPS for Git authentication. To connect to Git using HTTPS you'll first need to add a password to your account in Gitea:

  • Sign in to Gitea using OpenID
  • Click on your account (top right) and then click Settings
  • Fill in a password in the Account tab

After adding a password, you can now authenticate using your username (labs-user) and the password created in Gitea.

Create the private repository​

In the apps section in Otomi console, you'll see an app called Gitea. Click on it.

kubecfg

Now follow these steps:

  • Click on Sign In with OpenID

kubecfg

  • Click on + New Repository

kubecfg

  • Add the name blue for the repository
  • Optional: Enable Initialize Repository
  • Make Repository Private
  • Click on Create Repository

Your repo is now ready to be used!

kubecfg

Add the following 2 files to the repository:

Add Dockerfile:

FROM nginxinc/nginx-unprivileged:stable
COPY blue.html /usr/share/nginx/html/index.html
EXPOSE 8080

Add blue.html:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Sample Deployment</title>
    <style>
      body {
        color: #ffffff;
        background-color: blue;
        font-family: Arial, sans-serif;
        font-size: 14px;
      }
      h1 {
        font-size: 500%;
        font-weight: normal;
        margin-bottom: 0;
      }
      h2 {
        font-size: 200%;
        font-weight: normal;
        margin-bottom: 0;
      }
    </style>
  </head>
  <body>
    <div align="center">
      <h1>Welcome to Blue</h1>
    </div>
  </body>
</html>

In the following labs we are going to use the blue repository, but we'll also need a green repository. Create the green repository and add the 2 files, but change blue into green.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-30/index.html b/docs/get-started/labs/lab-30/index.html index 9a9f4d141..c77bac812 100644 --- a/docs/get-started/labs/lab-30/index.html +++ b/docs/get-started/labs/lab-30/index.html @@ -14,13 +14,13 @@ - +

Create custom dashboards

In the lab Using custom metrics we created a Workload with a ServiceMonitor so the Team's Prometheus can scrape our custom metrics. In this lab we are going to create a custom Grafana dashboard and add the dashboard to a Configmap so the Team's Grafana will automatically load the dashboard.

Create a dashboard in Grafana​

  1. In the left menu, click on Apps and open Grafana

  2. Go to the Grafana dashboard homepage

  3. In the top right click on New and then New Dashboard

  4. Click + Add visualization

  5. In the Query tab select Prometheus (default)

  6. In the A collapsible section, select a metric from the Metric drop-down list. In our example we use the application_greetings_total metric

  7. Click Run queries

  8. You should now see a Time series graph like this:

dashboards

  1. Save the dashboard in Grafana

Make the dashboard persistent​

You know know how to create a dashboard in Grafana using custom metrics. You could now save the dashboard, but if Grafana would get re-started, the dashboard would be gone. To make the dashboard persistent we need to add it to a configmap.

  1. Go to apps and open Gitea
  2. In the list of repositories there is a repository called otomi/team-<team-name>-argocd. Go to this repository.
  3. Click Add File and then New File
  4. Name the file my-custom-dashboard.yaml
  5. Add the following manifest to the file:
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-custom-dashboard
  labels:
    grafana_dashboard: "1"
    release: grafana-dashboards-labs # change labs to the name of your team
data:
  my-dashboard.json: |-
    # paste your dashboard json here
  1. Before commiting changes, go back to Grafana
  2. Click on Dashboard settings (in the top right)
  3. In the left menu click JSON model
  4. Copy the JSON model and paste it into the ConfigMap. Make sure to indent with 4
  5. Delete the dashboard created in Grafana
  6. Commit changes in Gitea

The dashboard will now automatically be loaded into Grafana.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-31/index.html b/docs/get-started/labs/lab-31/index.html index c5b35f7d8..5c6f3491f 100644 --- a/docs/get-started/labs/lab-31/index.html +++ b/docs/get-started/labs/lab-31/index.html @@ -14,13 +14,13 @@ - +

Create custom rules

Now we are exporting metrics, these metrics can also be used to generate alerts. To generate alerts, we first need to create a Prometheus Rule:

  1. Go to apps and open Gitea
  2. In the list of repositories there is a repository called otomi/team-<team-name>-argocd. Go to this repository.
  3. Click Add File and then New File
  4. Name the file my-custom-rules.yaml
  5. Add the following manifest to the file:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus: team-labs # change labs to the name of your team
  name: labs-custom-rules
spec:
  groups:
  - name: custom.rules
    rules:
    - alert: 50GreetingsReached
      annotations:
        description: We reached 50 greetings!
        summary: The number of greetings has reached more than 50.
      expr: application_greetings_total > 50
      for: 1m
      labels:
        severity: warning
  1. Commit changes in Gitea

See rules in Prometheus​

Now let's check to see if Prometheus has picked-up the rule:

  1. Go to Apps and open Prometheus
  2. In the menu click on Status and then Rules. You should now see the rule:

rules

  1. In the menu in Prometheus, click Alerts
  2. You should see an alert has been fired:

rules

See alerts in Alertmanager​

  1. Go to Apps and open Alertmanager
  2. You will see Alertmanager has received the alerts from Prometheus:

rules

If a receiver has been configured for the Team, like Slack or email, then you would also have received a message with the alert.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-32/index.html b/docs/get-started/labs/lab-32/index.html index ab5c60d17..b1f1ac382 100644 --- a/docs/get-started/labs/lab-32/index.html +++ b/docs/get-started/labs/lab-32/index.html @@ -14,13 +14,13 @@ - +

Create projects

A Project in Otomi is a collection of a Build, a Workload and a Service. The benefit of using Projects is that you can create a Build, a Workload and a Service in one run. Projects are ideal for developers to run multiple code branches next to each other and automatically update the deployment based on a push. In this lab we are going to create a Project and see how everything now comes together is one simple form.

Create a new Git repository​

  1. Create a new repo called hello-world
  2. Set the Default Branch to master
  3. Clone the Hello World Sample Application from the Red Kubes GitHub repository:
git clone https://github.com/redkubes/nodejs-helloworld
cd spring-petclinic
  1. Mirror the Hello World Sample Application to your hello-world repo:
git push --mirror https://gitea.<your-domain>/<your-user-name>/hello-world.git

Create a Project​

  1. Go to Project and click Create Project
  2. Fill in a name for the Project. This name is used for the Build (the name of the image) and the Workload. The Service will automatically select the ClusterIp service name based on the Workload name.
  3. Click Create build from source
  4. Click Next
  5. Choose Docker and fill in the repository URL of the hello-world repository
  6. Enable Trigger
  7. Select the Digest strategy for the Auto image updater
  8. The imageRepository is already filled in. Make sure the tag is identical to the tag used for the Build
  9. Use the default Chart values
  10. Click Next
  11. Under Exposure select External
  12. Click Submit

Get the webhook URL​

Before we can configure the webhook for the hello-world repo in Gitea, we will need the webhook URL. You can find this webhook URL for your build in the list of Builds. Add the webhook URL to your clipboard.

Also notice that the status of the Build shows an exclamation mark. This is because Otomi created the Pipeline, but the PipelineRun is not yet created because it was not triggered yet.

Create a Webhook​

  1. In Otomi Console, click on apps the left menu and then open Gitea
  2. In the top menu of Gitea, click on Explore and then on the hello-world repo
  3. Go to Settings (top right) and then to Webhooks
  4. Click Add Webhook and select Gitea
  5. In the Target URL, paste the webhook URL from your clipboard.
  6. Click Add Webhook

Trigger the build​

You can now trigger the build by doing a commit in the hello-world repo, or by testing the webhook. Let's test the webhook:

  1. In Gitea, go to the Settings (top right) of the hello-world repo and then to Webhooks
  2. Click on the webhook we just created
  3. In the bottom, click on Test Delivery

Check the status of the Workload​

Go to Workloads and click on the Argo CD application link of the Workload created by the Project. What do you see? The Argo CD application is still in a Degraded state because the image build has not completed yet. When the build in finished and the image can be pulled, the status of the application will automatically become Healthy.

Check the status of the Service​

When the state of the Workload becomes Healthy, the URL of the Service created by the Project will show the following page:

Hello World

Change the code and push the commit​

  1. Go to the hello-world repository
  2. Edit the package.json and set the Version to 1.4.0
  3. Commit the changes

Check the URL again. After a couple of minutes you will see the following page:

Hello World

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-4/index.html b/docs/get-started/labs/lab-4/index.html index 470c1c041..97ed2910e 100644 --- a/docs/get-started/labs/lab-4/index.html +++ b/docs/get-started/labs/lab-4/index.html @@ -14,13 +14,13 @@ - +

Create a CI pipeline

Kubernetes is a container orchestrator, so we need to create container images that we can deploy. Next to providing a Git service. Otomi also has a complete CI solution called Drone integrated. You can use Drone to create and run CI pipelines to build images and push them to your private image registry (Harbor).

Prerequisites​

Before you can use Drone to run CI pipelines, you will need to have:

  1. A Git repository
  2. Credentials to push images to the registry (your private registry on the platform)

Creating a build pipeline in Drone​

In the apps section in Otomi console, you'll see an app called Drone. Click on it.

kubecfg

  • Go to the Drone dashboard, and click on ‘SYNC’. You will now see your repo pop up in the REPOSITORIES list.

kubecfg

  • Click on the new repo and then click ‘ACTIVATE’.

kubecfg

Now we’ll need to add the Harbor push credentials (you can download the credentials in the Otomi Console) as secrets to Drone:

  • Click on your repository.
  • Under Settings, Click on secrets
  • Add the following 2 secrets:
REGISTRY_USERNAME = <harbor-account-name.
REGISTRY_PASSWORD = <the-token-of-the-account-name>

Now you'll need to add a Drone pipeline definition to our repo.

  • Add a .drone.yml file to your repo. This is an example you can use:
kind: pipeline
type: kubernetes
name: default
steps:
  - name: build-push
    image: plugins/docker
    settings:
      registry: harbor.<yourdomain>
      repo: harbor.<your-ip>.nip.io/team-demo/hello
      insecure: true
      username:
        from_secret: REGISTRY_USERNAME
      password:
        from_secret: REGISTRY_PASSWORD
      tags:
        - ${DRONE_BRANCH}

Make sure to adjust the registry and repo name in the .drone.yml file

In Drone, you will see the pipeline has automatically started building and then pushing the new image to Harbor.

kubecfg

If you use Harbor as a private registry, check to see if the repo has been created. You can now also use Trivy in Harbor to scan your image(s) for vulnerabilities.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-5/index.html b/docs/get-started/labs/lab-5/index.html index 5402d68ff..4e3fb9820 100644 --- a/docs/get-started/labs/lab-5/index.html +++ b/docs/get-started/labs/lab-5/index.html @@ -14,7 +14,7 @@ - + @@ -23,7 +23,7 @@ x509: certificate signed by unknown authority, go to the Otomi Console, and click Download CA (if you have not done so already); then copy the obtained file to ~/.docker/ca.crt or restart docker desktop.

  • Build and tag your image
docker build -t harbor.<your-domain>/<team-name>/<image-name>:<tag> .
  • Push the image to Harbor
docker push harbor.<your-domain>/<team-name>/<image-name>:<tag>
- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-6/index.html b/docs/get-started/labs/lab-6/index.html index b777e5fd4..0cc13ef89 100644 --- a/docs/get-started/labs/lab-6/index.html +++ b/docs/get-started/labs/lab-6/index.html @@ -14,13 +14,13 @@ - +

Build images from application source

info

Harbor needs to be activated for this lab.

When your team is using Harbor for private image registries, you can build images from source using pre-configured Tekton pipelines using the paketo task or the Kaniko task to build images from application source.

Build the blue image​

  1. In the left menu, click on Builds
  2. Click on Create Build
  3. Fill in the name blue for your build and a tag (default tag is latest)
  4. Choose Docker and fill in the repo URL for the blue repo created in the previous lab
  5. Click Submit

Otomi will now create a Tekton Pipeline and PipelineRun resource to build the image. This will take around 15-20 seconds. Then the PipelineRun will start building the image. During this time the status will show in progress:

build status

When the build is finished, the status will show healthy:

build status

To see the full PipelineRun of the build, go to the list of Builds and click on PipelineRun of the blue build. This will open the Tekton Dashboard and show the status of the PipelineRun of the build:

build status

When the build is ready you can see the image in Harbor:

  1. Open Harbor
  2. Click on the project of your team. Here you will see all the registries of the team, including the registry of the new build image

build status

Re-run the build (optional)​

To run the build again using Otomi Console, follow these steps:

  1. Change the tag of the build for example to v1.0.0
  2. Submit changes

To re-build the image using the same tag, restart the build pipeline using the Tekton cli in the Shell:

  1. Start a shell in Otomi Console

  2. Get the name of the pipeline

kubectl get pipelines
NAME                         AGE
docker-build-blue            41h
  1. Get the name of the pipelinerun:
kubectl get pipelineruns
NAME                       SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
docker-build-blue-latest   True        Succeeded   41h         41h
  1. Start the pipeline using the pipelinerun:
tkn pipeline start docker-build-blue --use-pipelinerun docker-build-blue-latest
PipelineRun started: docker-build-blue-latest-j5mmt
  1. In order to track the PipelineRun progress run:
tkn pipelinerun logs docker-build-blue-latest-j5mmt -f

But it's easier to just open the Tekton dashboard and Click on PipelineRuns.

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-7/index.html b/docs/get-started/labs/lab-7/index.html index 062214786..8de2fc204 100644 --- a/docs/get-started/labs/lab-7/index.html +++ b/docs/get-started/labs/lab-7/index.html @@ -14,13 +14,13 @@ - +

Scan your images for vulnerabilities

Prerequisites​

To automatically scan images for vulnerabilities, Automatically scan images on push in the Team project settings in Harbor needs to be enabled by the platform administrator:

image vulnerabilities

Scanning images​

When your team is using Harbor for private image registries, you can use Trivy to automatically scan your images on push. When Automatically scan images on push is enabled by the platform administrator, you can see the results of the scans by following these steps:

  • In the apps section in Otomi console, click on Harbor
  • Click on your project. You will only see the projects of the Teams that you are a member of
  • You will now see a list of the teams repositories
  • Click on the repository that contains the artifact (image) that you would like to investigate
  • In the list of artifacts, you can see a summary of the scan results

kubecfg

When you click on the scanned artifact, you'll see a more detailed report on all the vulnerabilities:

kubecfg

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-8/index.html b/docs/get-started/labs/lab-8/index.html index 6385e2d0c..6ea656056 100644 --- a/docs/get-started/labs/lab-8/index.html +++ b/docs/get-started/labs/lab-8/index.html @@ -14,13 +14,13 @@ - +

Create secrets

info

Hashicorp Vault needs to be activated for this lab.

note

Hashicorp Vault is being deprecated in Otomi. We are going to replace this app with solution based on SealedSecrets.

When the platform administrator has enabled Vault, you can use Vault to store and manage secrets. Secrets in Vault can be synchronized to your team namespace as Kubernetes secrets. In this part we'll first create a secret in Vault and then sync the secret to your team namespace using the Secrets option in Otomi Console.

Create a secret in Vault​

  • Open the Vault app in your team apps

kubecfg

  • Sign in with Method OIDC, click on Sign in with OIDC Provider and leave role blank

kubecfg

You are now automatically redirected to your team space (secrets/teams/team-labs) in Vault.

info

In your team space in Vault you will see the secret .keep-me. Do NOT remove this secrets. If you do, the team space in Vault will be removed.

  • Click on Create secret

kubecfg

  • Provide a name for the secret. We'll use the name hello. The name of the secret in this case will be: teams/team-labs/hello
  • Fill in a Key (TARGET in the example below) and a value
  • Click on save

kubecfg

The secret is now created in vault. Now we need to synchronize the secret in Vault to Kubernetes so the secret can be used in workloads.

Create a secret in Otomi​

  • In the left menu click Secrets
  • Click on Create secret
  • Provide a name for the secret. The name should match the name of the secret in Vault
  • Select the secret type (Generic in this case)
  • Under Entries fill in the keys (the keys of the secret in Vault)

kubecfg

  • Click submit
  • Now click on Deploy Changes on top of the left menu

The secret in Vault will now be synchronized to Kubernetes and can be used by the team in any workload. Otomi Console makes this easy by offering a secret selector during the creation of services.

info

In this lab we only covered using generic secrets. See here to see how you can create TLS and pull secrets

- + \ No newline at end of file diff --git a/docs/get-started/labs/lab-9/index.html b/docs/get-started/labs/lab-9/index.html index c3627cfa1..7bdce3a50 100644 --- a/docs/get-started/labs/lab-9/index.html +++ b/docs/get-started/labs/lab-9/index.html @@ -14,13 +14,13 @@ - +

Deploy your application

Now that you have access to the team namespace and have pushed your image to Harbor, you can now deploy your application.

In this case we'll use a demo app called hello. If you like you can clone the repo

git clone https://github.com/redkubes/nodejs-helloworld.git

And then tag and build the image as you have done in the Push images lab.

Create a Deployment and Service​

Create a hello-svc.yaml file and copy/paste the following 2 Kubernetes manifests:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-svc
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-svc
  template:
    metadata:
      labels:
        app: hello-svc
    spec:
      containers:
        - name: hello-svc
          image: harbor.<your-domain>/<team-name>/<image-name>:<tag>
          resources:
            limits:
              memory: '128Mi'
              cpu: '200m'
            requests:
              memory: '64Mi'
              cpu: '100m'
          securityContext:
            runAsUser: 1001
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: hello-svc
spec:
  selector:
    app: hello-svc
  ports:
    - port: 80
      targetPort: 8080

Now apply the manifest to Kubernetes:

kubectl apply -f hello-svc.yaml

Check to see if the pod is running and the service has been created:

kubectl get pod
kubectl describe svc hello
note

The example here is only a very simplified one. You can dive into the world of Kubernetes deployments, or you can ask your platform administrator to enable Knative Serving. Knative will then take care of auto scaling for you. We will also soon release a new feature that will help to remove the struggle of creating and managing Kubernetes manifests. Stay tuned!

- + \ No newline at end of file diff --git a/docs/get-started/labs/overview/index.html b/docs/get-started/labs/overview/index.html index e42e389c1..5d997ea41 100644 --- a/docs/get-started/labs/overview/index.html +++ b/docs/get-started/labs/overview/index.html @@ -14,13 +14,13 @@ - +

Labs Overview

Welcome to Otomi! If you are going to use Otomi or like to learn Kubernetes, these labs are for you. Step by step we'll guide you in how to build, deploy, secure and observe containerized applications on Kubernetes. The labs cover the most common activities performed by developer- and/or DevOps teams when using Kubernetes with Otomi.

Make sure everything is ready to get started

Prerequisites​

Provision a Kubernetes cluster and install Otomi​

Create code repositories and build images

Create private Git repositories​

Build images​

Trigger builds​

Create workloads

Create secrets​

Create Kubernetes resources with Argo CD​

Explore the Catalog​

Create a workload using the developer catalog​

Configure the auto image updater​

Create a PostgreSQL database​

Expose workloads

Publicly expose workloads​

Secure workloads

Check policy compliance​

Scan images for vulnerabilities​

Scan your running containers for vulnerabilities​

Monitor and debug workloads

View container logs​

View container metrics​

Using custom metrics​

Create custom dashboards​

Create custom rules​

Monitoring availability​

Monitor databases​

Advanced Labs

Configuring network policies​

Tracing with OpenTelemetry​

Canary Deployments​

- + \ No newline at end of file diff --git a/docs/get-started/overview/index.html b/docs/get-started/overview/index.html index 22e1a366a..1434c0095 100644 --- a/docs/get-started/overview/index.html +++ b/docs/get-started/overview/index.html @@ -14,13 +14,13 @@ - +

Overview

How to get started with Otomi

Step 1: Read the prerequisites​

Know what is required to install Otomi.

Step 2: Install Otomi​

Setup a Kubernetes cluster in your favourite cloud or infrastructure and install Otomi on it. The examples on how to setup a Kubernetes cluster are only to help you get started.

Step 3: Activate your installation ​

Activate your Otomi installation on otomi.cloud

Step 4: Explore Otomi using the Labs​

Otomi Labs contains a set of labs to cover all the activities performed by developer- and/or DevOps teams supported by Otomi.

- + \ No newline at end of file diff --git a/docs/get-started/prerequisites/index.html b/docs/get-started/prerequisites/index.html index 852efae59..cf71c0a00 100644 --- a/docs/get-started/prerequisites/index.html +++ b/docs/get-started/prerequisites/index.html @@ -14,13 +14,13 @@ - +

Prerequisites

Client binaries​

When installing Otomi using the chart, make sure the following client binaries exist:

  • Kubectl to access the cluster
  • Helm for helm chart installation of Otomi

Kubernetes​

Otomi requires a (Vanilla) Kubernetes cluster.

Versions​

Otomi currently supports the following Kubernetes versions:

  • 1.25
  • 1.26
  • 1.27

Minimal compute resource requirements​

Otomi requires a node pool with at least 12 vCPU and 12 GiB RAM. Note that this is the requirements for a minimal install. When activating more apps, you'll probably need more resources.

CNI​

To use the network policies feature in Otomi, make sure to install the Calico CNI or any other CNI that supports Kubernetes network polices.

CSI​

Install a CSI driver for exposing block and file storage systems to containerized workloads.

Supported Providers​

Azure (AKS)​

To install Otomi on a AKS cluster in Azure, use the azure provider. The azure provider includes creating optimized storage classes and optional integration with the a Application Gateway Ingress Controller add-on.

Amazon Web Services (EKS)​

To install Otomi on a EKS cluster in AWS, use the aws provider.

Google Cloud Platform (GKE)​

To install Otomi on a GKE cluster in GCP, use the google provider.

Digital Ocean​

To install Otomi on a Kubernetes cluster in Digital Ocean, use the digitalocean provider. Otomi is also available in the Digital Ocean marketplace.

OVH cloud​

To install Otomi on a OVHcloud Managed Kubernetes Service, use the ovh provider.

Linode Kubernetes Engine (LKE)​

To install Otomi on a Linode Kubernetes Engine cluster, use the linode provider.

Vultr (VKE)​

To install Otomi on a Vultr Kubernetes Engine (VKE) cluster, use the vultr provider.

Civo​

To install Otomi on a Civo K3s cluster, use the civo provider.

Otomi on CIVO requires at least:

  • A node pool with 3 Large Standard nodes (4 CPU Cores and 8 GB RAM)
  • Kubernetes version 1.26 or 1.27

Otomi installs and configures Nginx as a default ingress controller. When launching from the marketplace, make sure to unselect the default Traefik v2 (NodePort).

All others​

Use the custom provider for all other clouds, and when running Kubernetes on your own hardware. The custom provider uses the default available storage classes. The only requirement for using the custom provider is to be able to create a Kubernetes LoadBalancer Service that can obtain an external accessible IP.

- + \ No newline at end of file diff --git a/docs/get-started/promotions/index.html b/docs/get-started/promotions/index.html index 04400cd88..516a60009 100644 --- a/docs/get-started/promotions/index.html +++ b/docs/get-started/promotions/index.html @@ -14,13 +14,13 @@ - +

November / December 2023

This is your chance to win an Amazon Gift Card!

Terms & Conditions​

The only thing you'll need to do for your chance to win an Amazon Gift Card is to install Otomi Community edition in November or December 2023.

In the first week of January 2024, we'll announce all the winners. Make sure you'll provide your full name when registering your installation at portal.otomi.cloud.

Need help when trying to install Otomi? Simply join our Slack Channel and we'll try to help you out.

We are also curious to learn where we can improve Otomi to make it even better. So don't hesitate to create an enhancement issue on GitHub. And when there, please give Otomi a ⭐️⭐️⭐️

Thank you and good luck! Let's go 🚀🚀

- + \ No newline at end of file diff --git a/docs/tutorials/overview/index.html b/docs/tutorials/overview/index.html index bac0b7d9c..02ff056c3 100644 --- a/docs/tutorials/overview/index.html +++ b/docs/tutorials/overview/index.html @@ -14,13 +14,13 @@ - +

Tutorial Overview

This section contains tutorials for more advanced installation scenario's.

  1. Install and activate Otomi with minimal vales

We'll soon add tutorials for:

  • Install Otomi on EKS using Route53 for DNS and AWS Customer managed keys for encrypting otomi-vales
  • Install Otomi on Azure AKS using a public DNS zone
- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-1/index.html b/docs/tutorials/tutorial-1/index.html index 5d12dc656..fe1a2bfaa 100644 --- a/docs/tutorials/tutorial-1/index.html +++ b/docs/tutorials/tutorial-1/index.html @@ -14,14 +14,14 @@ - +

Installing Otomi

To go through the tutorials, you first need to install Otomi on a running Kubernetes cluster.

In this first tutorial, we'll be installing Otomi using helm with minimal values.

Prerequisites​

Instructions​

  1. Add Otomi helm chart repository

    helm repo add otomi https://otomi.io/otomi-core && \
    helm repo update

  2. Install Otomi with chart values

    helm install otomi otomi/otomi \
    --set cluster.name=$CLUSTERNAME \
    --set cluster.provider=$PROVIDER

  3. Monitoring the Chart install

    # The chart deploys a Job (`otomi`) in the `default` namespace
    # Monitor the status of the job
    kubectl get job otomi -w
    # watch the helm chart install status (optional)
    watch helm list -Aa

  4. When the installer job is finished, go to the end of the logs

    kubectl logs jobs/otomi -n default -f

    There you will see the following:

    2022-04-01T10:01:59.239Z otomi:cmd:commit:commit:info                                                                                            
    ################################################################################################
    #  To start using Otomi, go to https://<your-ip>.nip.io and sign in to the web console         #
    #  with username "otomi-admin" and password "password".                                        #
    #  Then activate Drone. For more information see: https://otomi.io/docs/get-started/activation #
    ################################################################################################

  5. Sign in to the web UI (Otomi Console)

    Once Otomi is installed, go to the url provided in the logs of the installer job and sign in to the web UI with the provided username and password.

  6. Add the auto generated CA to your keychain (optional)

    Since we install Otomi without proving a custom CA or using LetsEncrypt, the installer generated a CA. This CA is of course not trusted on your local machine. To prevent you from clicking away lots of security warning in your browser, you can add the generated CA to your keychain:

  • In the left pane of the console, click on "Download CA"

  • Double click the downloaded CA.crt or add the CA to your keychain on your mac using the following command:

    # On Mac
    sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/Downloads/ca.crt  
    # On Windows(PowerShell - Run as Administrator)
    # Use certutil:
    certutil.exe -addstore root <downloaded cert path>
    # Or 
    Import-Certificate -FilePath "<downloaded cert path>" -CertStoreLocation Cert:\LocalMachine\Root
    # Restart the browser

    But you could also run Chrome (sorry Msft folks ;) in insecure mode:

    alias chrome-insecure='/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ignore-certificate-errors --ignore-urlfetcher-cert-requests &> /dev/null'
  1. Activate Drone:
  • In the side menu of Otomi Console under platform click on apps and then on the Drone app
  • Sign in locally with as otomi-admin and the password provided in the logs of the installer job
  • Click on Authorize Application
  • Click on Submit on the Complete your Drone Registration page. You don't need to fill in your Email, Full Name or Company Name if you don't want to
  • Click on the otomi/values repository
  • Click on + Activate Repository
- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-10/index.html b/docs/tutorials/tutorial-10/index.html index b3c94523a..b90c98e3a 100644 --- a/docs/tutorials/tutorial-10/index.html +++ b/docs/tutorials/tutorial-10/index.html @@ -14,13 +14,13 @@ - +

Creating a micro service architecture

In this tutorial we are going to deploy multiple services from different teams and expose them using a shared domain, but each on their own path. We will use on-the-fly Knative services for speed and simplicity.

Prerequisites​

  1. You are familiar with Knative
  2. Knative is enabled in Otomi. (Check the Apps section under Platform.)
  3. Two teams are created. We will refer to them as alpha and beta. (It is not necessary to Deploy first.)

Instructions​

  1. Select team alpha in the top bar, select Services from the Team alpha menu section and click on Create Service, and choose New knative service.

  2. Provide the following values and submit:

  • name: sir
  • Run As User: 1001
  • Repository: otomi/nodejs-helloworld
  • Tag: v1.2.12
  • Limits: CPU=100m, Memory=128Mi
  • Requests: CPU=50m, Memory=64Mi
  • env: TARGET=world, I just woke up!, SERVANTS=servant-1,servant-2
  • Check Scale to zero
  • Exposure: Ingress
  • Uncheck Use team domain
  • host: hello-multi (DNS zone can be left as-is)

Click Deploy to start the service and domain registration, as that might take time. Plus we want the service to go to sleep as we intend to wake it up later (it serves a purpose, hope you spot it later on ;).

  1. Under the same team create the last New knative service service with the same values but the following diff and submit:
  • name: informant
  • Exposure: Cluster
  • Leave Scale to zero unchecked
  1. Under the same team create another New knative service service with the same values but with the following diff and submit:
  • name: servant-1
  • paths: /servant-1
  • env: TARGET=sir
  1. Select team beta and create a New knative service service with the same values but the following diff and submit:
  • name: servant-2
  • paths: /servant-2
  • env: TARGET=sir, INFORMANT=http://informant.team-alpha
  1. Now click Deploy Changes again and watch the deployment finish in Drone.

Conclusion​

In effect what we have done is create the following workloads for team alpha:

  • master.team-alpha exposed via https://hello-multi.$domain
  • servant-1.team-alpha exposed via https://hello-multi.$domain/servant-1
  • informant.team-alpha not exposed publicly, but only able to receive requests from servant-2.team-beta.

And for team beta:

  • servant-2.team-beta exposed via https://hello-multi.$domain/servant-2

Bonus: Add network policies to make sure no unforeseen traffic is routed :)

- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-2/index.html b/docs/tutorials/tutorial-2/index.html index 4c3d70452..2af02aaec 100644 --- a/docs/tutorials/tutorial-2/index.html +++ b/docs/tutorials/tutorial-2/index.html @@ -14,13 +14,13 @@ - +

Creating teams

In this tutorial, we are going to create a Team in Otomi. Teams in Otomi serve the following purpose:

  • Creating a namespace on the cluster, configuring RBAC and setting default quota's

  • Provide self-service options for team members in Otomi Console

  • Isolate traffic between teams

  • Optionally: Separate team metrics and logs. When multi-tenancy is not enabled (default), metrics and logs are not separated (providing all users the admin role to see cluster wide metrics and logs)

info

The multi-tenancy option in Otomi is not enabled by default. Team metrics and logs will be separated per team when multi-tenancy is enabled. When multi-tenancy is disabled this effectively gives all users the admin role for logs and metrics, including metrics and logs of all platform services. For this lab, we will not enable multi-tenancy. To see if multi-tenancy is enabled, go to Settings under the Platform section in the side menu and then select Otomi. At the bottom of the page you will see the flag Multi-tenancy.

Let's create a Team!

Instructions​

  1. In the side menu, click on Teams under the Platform section

  2. Click on Create Team

  3. Provide a name for the team. For the purpose of these tutorials we recommend using demo

  4. Under NetworkPolicy, disable Network policies and Egress control (we will activate this later on)

  5. Leave all other settings default

  6. Click on submit

  7. Click on Deploy Changes (this will become active after in the side menu after you submit a change)

  8. Select your team in the top bar. Here you can select your context (cluster and team)

  9. In the side menu, the team section will now become visible

- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-3/index.html b/docs/tutorials/tutorial-3/index.html index 45ae97ea3..4dc47d166 100644 --- a/docs/tutorials/tutorial-3/index.html +++ b/docs/tutorials/tutorial-3/index.html @@ -14,13 +14,13 @@ - +

Activating tools

Core Apps​

Otomi by default installs a minimal set of core applications. With the Core apps, Otomi offers an advanced ingress architecture using Nginx, Istio, Keycloak, Certmanager, and Oauth2 along with developer self-service.

Optional Apps​

Next to the Core apps, Otomi offers optional apps like Knative, Harbor, Vault, Kubeapps, Prometheus, Loki, Alertmanager, and more. These apps are all fully integrated and can be activated by dragging them to the active apps section in the Console.

In this lab we are going to activate Loki for logging.

Instructions​

  1. Go to Apps under the Platform section in the side menu and Drag and Drop Loki from the Disabled apps to the Enabled apps. Notice that Grafana and Prometheus will also be enabled. This is because Loki requires Grafana, and Grafana requires Prometheus and therefore they are also installed because of these dependencies.

  2. Click on Deploy Changes

  3. To see the progress of the installation of Loki, go to apps under the Platform section and click on Drone. In the top right you will see a play button. Click on it. The Drone app will now open in a new tab. Click on the otomi/values repository and then on the last build execution. When the apply step is finished, Loki and Grafana will be installed and ready to use.

  4. Go to the Apps section again and click on Loki. In the app bar, click on Values. The Loki chart has been installed with sane default values to support the most common use cases. Click on Duration to see the default value. All the defaults (specified in the Otomi values schema can be modified.

  5. In the app bar, click on Raw values. In the Raw values, all values of the Loki chart that are not provided with defaults from the Otomi values schema can be used here.

  6. Click on the play button. A new tab wil open and here you can execute queries to search for logs. Add the following query: {namespace="team-$TEAM-NAME"}. Now you will see all the logs of containers running in the namespace of your team. Copy the path after .nip.io from the address bar in your browser.

  7. Go back to the console and in the Loki app, click on Shortcuts. Click edit and the Add item. Fill in a title (like "$TEAM-NAME logs"), a description (like "The logs of $TEAM-NAME") and paste the copied path. Now click submit. The shortcut you now created can be used to go directly to Loki and see the result of your query.

- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-4/index.html b/docs/tutorials/tutorial-4/index.html index a7fa54d59..6fa83867b 100644 --- a/docs/tutorials/tutorial-4/index.html +++ b/docs/tutorials/tutorial-4/index.html @@ -14,13 +14,13 @@ - +

Build, tag and push an image to Harbor

note

When Otomi is installed without using Let's Encrypt production certificates, make sure you download the CA.crt, add it to your Keychain and restarted Docker.

In this tutorial, you are going to:

  1. Activate Harbor
  2. Build an image and push it to Harbor in Otomi
  3. Create a Kubernetes Deployment and Service
  4. Publicly expose the Hello World app using Otomi

When you created a Team in Otomi, Otomi will automatically create a project for the team in Harbor. In this tutorial we'll assume you have created a team called demo.

Instructions​

  1. Activate Harbor

Go to Apps under the Platform section in the side menu and Drag and Drop Harbor from the Disabled apps to the Enabled apps.

  1. Create a robot account in Harbor
note

Robot accounts for teams can only be created by users with the otomi-admin role

  • Go to https://harbor.<your-ip>.nip.io
  • Click 'Login with OIDC Provider'
  • Fill in your user name and click save
  • Under Administration, click Robot Accounts
  • Click on + New Robot account
  • Provide a name for the new robot account: team-demo-push
  • Set an Expiration time
  • Select team-demo and optionally change the permissions
  • Click Add
  • Copy the generated token
  1. Download the demo application used in this tutorial

Clone the repo used for this tutorial:

git clone https://github.com/redkubes/nodejs-helloworld.git
  1. Login to Harbor

Login with username otomi-team-demo-push & password: token

docker login -u 'otomi-team-demo-push' -p '$token' harbor.<your-ip>.nip.io
  1. Build, tag and push the image

Build and tag the image:

docker build -t harbor.<your-ip>.nip.io/team-demo/hello-world:latest .

Push the image to Harbor:

docker push harbor.<your-ip>.nip.iom/team-demo/hello-world:latest

Now go to the team-demo project and verify that the hello-world repository has been created.

- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-5/index.html b/docs/tutorials/tutorial-5/index.html index 4af4efedc..011c00a42 100644 --- a/docs/tutorials/tutorial-5/index.html +++ b/docs/tutorials/tutorial-5/index.html @@ -14,13 +14,13 @@ - +

Create a Workload

In his tutorial, we are going to create a Workload in Otomi.

  • In the top bar in Otomi Console, select team: demo
  • In the left menu panel under Team demo, click Workloads then click on Create Workload
  • Fill in the form with these values:
  1. Name: hello-world
  2. URL of the Git repo: https://github.com/redkubes/nodejs-helloworld.git
  3. Path: chart/hello-world

Click submit. You will now be asked to provide values for the chart. Click Edit and add the following value:

replicaCount: 2
  • Click Submit
  • Click on Deploy Changes (the Deploy Changes button in the left panel will light-up after you click on submit)

The new workload will now be in the list of workloads.

  • Click on Application

What do you see?

Go back to Otomi Console to edit the values of the workload. Set the replicacount to 1.

What do you see happening in the Argo CD app?

- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-6/index.html b/docs/tutorials/tutorial-6/index.html index d9193980a..5f3a37cb3 100644 --- a/docs/tutorials/tutorial-6/index.html +++ b/docs/tutorials/tutorial-6/index.html @@ -14,13 +14,13 @@ - +

Create a Service

In his tutorial, we are going to create a Service in Otomi to publicly expose the ClusterIP service of the Workload we deployed in the previous tutorial.

  • In the top bar in Otomi Console, select team: demo
  • In the left menu panel under Team demo, click Services then click on Create Service
  • Fill in the form with these values:
  1. Name: hello-world (the name of the ClusterIP service we deployed in the previous tutorial)
  2. Exposure: Public
  • Click on Submit
  • Click on Deploy Changes (the Deploy Changes button in the left panel will light-up after you click on submit)

Deploying changes in Otomi usually takes just a couple of minutes depending on the amount of resources available on your cluster.

Go to https://hello-world.team-demo.<your-ip>.nip.io/ to see the app.

- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-7/index.html b/docs/tutorials/tutorial-7/index.html index fc717ba98..e264aebad 100644 --- a/docs/tutorials/tutorial-7/index.html +++ b/docs/tutorials/tutorial-7/index.html @@ -14,13 +14,13 @@ - +

Using Knative

In this lab, we are going to:

  • Activate Knative
  • Create a Knative service with manifest (using ArgoCD)

Activate Knative​

Go to the Apps section under Platform in the side menu and Drag and Drop Knative from the Disabled apps to the Enabled apps and Deploy Changes

Create a Knative service with manifest (using ArgoCD)​

  1. Open the Gitea app
  2. In Gitea (click Explore in the top menu) you will see a repo created by Otomi for each team, called otomi/team-demo-argocd
  3. Go to the repo and create a new file called hello-ksvc.yaml and copy/paste the following YAML manifest:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-ksvc
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: '1'
        policy.otomi.io/ignore-sidecar: container-limits,psp-allowed-users
    spec:
      containers:
        - image: harbor.<your-ip>.nip.io/team-demo/hello-world:demo
          securityContext:
            runAsUser: 1001
  1. Open the ArgoCD app
  2. In ArgoCD, click on the team-demo application

You can now see that the Knative service is created.

  1. Optionally you can now expose this service by creating a Service in Otomi.
info

Comming soon: Let Otomi deploy your Knative service by generating a Helm chart for your Knative service

- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-8/index.html b/docs/tutorials/tutorial-8/index.html index ff8a8baa8..27a28d288 100644 --- a/docs/tutorials/tutorial-8/index.html +++ b/docs/tutorials/tutorial-8/index.html @@ -14,13 +14,13 @@ - +

Using secrets

In his tutorial, you are going to:

  • Create a secret in Hashicorp Vault
  • Create a Secret in Otomi
  • Use a secret in your workload

Create a secret in Hashicorp Vault​

  • In the left panel under the Team demo, click Otomi Apps then click on Vault
  • Sign in with Method OIDC, skip role and click on Sign in with OIDC Provider

You are now automatically redirected to the team space teams/team-demo/created in Vault.

  • Click on Create secret
  • Provide a name for the secret. We'll use the name hello. The name of the secret will be: teams/team-demo/hello
  • In the key field, fill in TARGET
  • In the value field, fill in party people
  • Click on save

The secret is now created in vault. In the next tutorial, you are going to "inject" the secret in the Otomi service configuration.

Create a secret in Otomi​

  • In the left panel under the Team demo, click Secrets
  • Click on Create secret
  • Provide a name for the secret. The name should match the name of the secret in Vault. Use the name hello
  • Select Generic (default)
  • Under Entries fill in TARGET (the key of the secret in Vault)
  • Click Submit
  • Click on Deploy Changes in the left pane of the console

Note: under the hood an open source tool called external-secrets is at work that will transform a Vault secret into a regular Kubernetes secret.

The secret in Vault is now mapped and can be used by the team in any workload. Otomi Console makes this easy by offering a secrets selector during creation of services.

Use a secret in your workload​

Add the following snippet to the hello-ksvc.yaml file created in the previous tutorial to the spec: section of the Knative service:

    spec:
      containers:
        - image: harbor.<your-ip>.nip.io/team-demo/hello-world:demo
          securityContext:
            runAsUser: 1001
          env:
          - name: TARGET
            valueFrom:
              secretKeyRef:
                name: hello
                key: TARGET

And apply the manifest to Kubernetes:

bash kubectl apply -f hello-svc.yaml


Go to https://hello.team-demo.<your-ip>.nip.io/

As you can see, the text on the page now shows the value `party people` of the secret you created in Vault.

You can do the same for the Knative service `hello-ksvc`.
- + \ No newline at end of file diff --git a/docs/tutorials/tutorial-9/index.html b/docs/tutorials/tutorial-9/index.html index 8ec1eca6b..2d78c40e1 100644 --- a/docs/tutorials/tutorial-9/index.html +++ b/docs/tutorials/tutorial-9/index.html @@ -14,13 +14,13 @@ - +

Configuring network policies

In this tutorial we are going to deploy a multi tier web application, called guestbook, register the 3 K8s services in Otomi and configure public access to the frontend service. Next, we will turn on the Network policies option for the team.

Instructions​

  1. Install the Guestbook application resources:
kubectl apply -f https://raw.githubusercontent.com/redkubes/workshops/main/04-netpols/guestbook.yaml -n team-$TEAM-NAME
  1. Get the names of the created ClusterIP services:
kubectl get svc -n team-<$TEAM-NAME>

You will see 3 services:

NAME             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
frontend         ClusterIP   10.0.183.235   <none>        80/TCP     6m44s
redis-follower   ClusterIP   10.0.135.61    <none>        6379/TCP   6m44s
redis-leader     ClusterIP   10.0.82.226    <none>        6379/TCP   6m44s

  1. Go to Otomi Console. Make sure you have selected your team in the top bar en and then click the Services item under your team in the side menu.

  2. We will now first add the created frontend service to Otomi. Click Create Service.

  3. Fill in the name frontend.

  4. Under Exposure, select Ingress. Leave all other settings under exposure default.

  5. Leave all other settings default and click submit.

  6. Click Deploy Changes.

info

After the changes have been deployed (this will take a couple of minutes), you will see that the service we just created has a host name. Click on the host name to get access to the guestbook frontend. submit a few messages on the application.

  1. Register the redis-follower and redis-leader services via the otomi-console. Make sure to provide the correct port (6379) and leave all other settings default (so no exposure) and submit. You don't need to Deploy Changes after every submit.
info

When you create a service in Otomi with ingress Cluster, the K8s service will be added to the service-mesh in Otomi. When you create services in Otomi, the Istio Gateway is automatically configured and Istio virtual services are also automatically created.

Notice that the guestbook frontend still works!

  1. In Otomi Console go to your team and then click the Settings item.

  2. Under Network policy, enable Network policies. Click submit and then Deploy Changes

info

Now go to the Guestbook application and notice that your messages have disappeared and you can't submit new messages. This is because traffic between the frontend and the redis-leader and redis-follower services is not permitted anymore.

Let's fix this

  1. In the otomi-console, click on the redis-leader service.

  2. Under Network policies, select Allow selected and click add item. Add the following 2 items and submit:

Team nameService Name
$TEAM-NAMEfrontend
$TEAM-NAMEredis-follower

Before deploying changes, go to the redis-follower service and do the same, but in this case only allow the frontend service:

Team nameService Name
$TEAM-NAMEfrontend
$TEAM-NAMEredis-leader

Now Deploy Changes

Notice that the Guestbook app works again.

- + \ No newline at end of file diff --git a/docs/tutorials/tutorials/create-k8s-service/index.html b/docs/tutorials/tutorials/create-k8s-service/index.html index f86816e1d..5a571e181 100644 --- a/docs/tutorials/tutorials/create-k8s-service/index.html +++ b/docs/tutorials/tutorials/create-k8s-service/index.html @@ -14,13 +14,13 @@ - +

Create a Kubernetes service

In this tutorial, we are going to deploy the image we pushed to harbor in the previous tutorial, by creating a Kubernetes Deployment and Service.

Create a Deployment and Service​

Create a hello-svc.yaml file and copy/paste the following 2 Kubernetes manifests:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-svc
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-svc
  template:
    metadata:
      annotations:
        policy.otomi.io/ignore-sidecar: container-limits,psp-allowed-users
      labels:
        app: hello-svc
    spec:
      containers:
        - name: hello-svc
          image: harbor.<your-ip>.nip.io/team-demo/hello-world:latest
          resources:
            limits:
              memory: '128Mi'
              cpu: '200m'
            requests:
              memory: '64Mi'
              cpu: '100m'
          securityContext:
            runAsUser: 1001
          ports:
            - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: hello-svc
spec:
  selector:
    app: hello-svc
  ports:
    - port: 80
      targetPort: 8080

Deploy the deployment and service​

In Otomi console, select team demo in the top bar. On the bottom of the left panel, click on download KUBECFG.

Now export the KUBECFG to set the kubectl context:

export KUBECONFIG=$path-to-your-kubeconfig.yaml

And apply the manifest to Kubernetes:

kubectl apply -f hello-svc.yaml

Check to see if the pod is running and the service has been created:

kubectl get pod
kubectl describe svc hello
- + \ No newline at end of file diff --git a/docs/tutorials/tutorials/create-knative-service/index.html b/docs/tutorials/tutorials/create-knative-service/index.html index 97f2d5d5e..cae8615ff 100644 --- a/docs/tutorials/tutorials/create-knative-service/index.html +++ b/docs/tutorials/tutorials/create-knative-service/index.html @@ -14,13 +14,13 @@ - +

Create a Knative service

In this tutorial, you are going to deploy the image you build, tagged and pushed to harbor in the previous tutorial by creating a Knative service.

Activate Knative​

Go to Apps under the Platform section in the side menu and Drag and Drop Knative from the Disabled apps to the Enabled apps and click on Deploy Changes in the left menu.

Create a Knative Service​

Create a hello-ksvc.yaml file and copy/paste the following Kubernetes manifests:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-ksvc
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: '1'
        policy.otomi.io/ignore-sidecar: container-limits,psp-allowed-users
    spec:
      containers:
        - image: harbor.<your-ip>.nip.io/team-demo/hello-world:demo
          securityContext:
            runAsUser: 1001

Deploy the Knative Service​

If you haven't done already, first set your kubectl context:

In Otomi console, select team demo in the top bar. On the bottom of the left panel, click on download KUBECFG.

Now export the KUBECFG to set the kubectl context:

export KUBECONFIG=$path-to-your-kubeconfig.yaml

And apply the manifest to Kubernetes:

kubectl apply -f hello-ksvc.yaml

Check if the Knative service has been created:

kubectl describe ksvc hello-ksvc
- + \ No newline at end of file diff --git a/docs/tutorials/tutorials/create-ksvc-otomi/index.html b/docs/tutorials/tutorials/create-ksvc-otomi/index.html index 1100bfe11..d48dd78d6 100644 --- a/docs/tutorials/tutorials/create-ksvc-otomi/index.html +++ b/docs/tutorials/tutorials/create-ksvc-otomi/index.html @@ -14,13 +14,13 @@ - +

Create and expose a Knative service with Otomi

In his tutorial, we are going to create a Knative service with Otomi Console and publicly expose it.

  • Go to the Apps section under Platform in the side menu and Drag and Drop Knative from the Disabled apps to the Enabled apps and Deploy changes
  • In the top bar in Otomi Console, select team demo
  • In the side menu under the Team demo, click Services then click on Create Service
  • Fill in the form with these values:
  1. Name: hello-otomi
  2. Service type: New Knative service
  3. In the Security context block, fill in 1001 in the Run As User field
  4. In the Container image block, fill in the name of the image you previously pushed to Harbor in the Repository field and fill in latest in the Tag field
  5. In the Container resources block, fill in the Limits and Requests (use the provided values: 50m and 64Mi)
  6. Exposure: Public
  7. Click on Submit
  8. Click on Deploy Changes (the Deploy Changes button in the left panel will light-up after you click on submit)

Deploying changes in Otomi usually takes just a couple of minutes.

Go to https://hello-otomi.team-demo.<your-ip>.nip.io/ to see the app.

- + \ No newline at end of file diff --git a/docs/tutorials/tutorials/use-secret/index.html b/docs/tutorials/tutorials/use-secret/index.html index c91c45038..ca4575709 100644 --- a/docs/tutorials/tutorials/use-secret/index.html +++ b/docs/tutorials/tutorials/use-secret/index.html @@ -14,13 +14,13 @@ - +

Use secrets in Kubernetes

In his tutorial, you are going to use the secret created in Hashicorp Vault and added to Kubernetes using the Otomi Secrets feature in a Kubernetes deployment.

Add the following snippet to the hello-svc.yaml file created in the previous tutorial to the spec: section of the deployment:

env:
  - name: TARGET
    valueFrom:
      secretKeyRef:
        name: hello
        key: TARGET

And apply the manifest to Kubernetes:

bash kubectl apply -f hello-svc.yaml


Go to https://hello.team-demo.<your-ip>.nip.io/

As you can see, the text on the page now shows the value `party people` of the secret you created in Vault.

You can do the same for the Knative service `hello-ksvc`.
- + \ No newline at end of file diff --git a/index.html b/index.html index 08d4ed886..9a88880d3 100644 --- a/index.html +++ b/index.html @@ -14,13 +14,13 @@ - +

Otomi logoSelf hosted DevOps PaaS for Kubernetes

A paved road for DevOps teams from code to production

Get Started

Build, Deploy and Run applications at scale

With one consistent experience on any CNCF conformant Kubernetes cluster across public cloud, on-premise and hybrid cloud

Otomi web console
- + \ No newline at end of file diff --git a/product/architecture/index.html b/product/architecture/index.html index e968178fc..2a58cf275 100644 --- a/product/architecture/index.html +++ b/product/architecture/index.html @@ -14,13 +14,13 @@ - +
-

Otomi Projects

Otomi consists out of the following projects:

Projectopen source
otomi-coreYes
otomi-tasksYes
otomi-clientsYes
otomi-consoleNo
otomi-apiNo

Otomi Core​

Otomi Core contains all the integrated applications and is made available (per release) as a container image.

Otomi Core also contains the source code for Otomi CLI. Otomi CLI can be used for advanced initial configuration (bootstrapping), deployment, sync, push, template validation, and much more.

Integrated K8s applications​

Otomi Core is the heart of Otomi and contains a suite of the following integrated Kubernetes applications:

  • Istio: The service mesh framework with end-to-end transit encryption
  • Keycloak: Identity and access management for modern applications and services
  • Cert Manager - Bring your own wildcard certificate or request one from Let's Encrypt
  • Nginx Ingress Controller: Ingress controller for Kubernetes
  • External DNS: Synchronize exposed ingresses with DNS providers
  • Drone: Continuous integration platform built on Docker
  • Gitea: Self-hosted Git service
  • Velero: Back up and restore your Kubernetes cluster resources and persistent volumes
  • Argo CD: Declarative continuous deployment
  • Knative: Deploy and manage serverless workloads
  • Kaniko: Build container images from a Dockerfile
  • Prometheus: Collecting container application metrics
  • Grafana: Visualize metrics, logs, and traces from multiple sources
  • Grafana Loki: Collecting container application logs
  • Harbor: Container image registry with role-based access control, image scanning, and image signing
  • HashiCorp Vault: Manage Secrets and Protect Sensitive Data
  • OPA/Gatekeeper: Policy-based control for cloud-native environments
  • Jaeger: End-to-end distributed tracing and monitor for complex distributed systems
  • Kiali: Observe Istio service mesh relations and connections
  • Minio: High performance Object Storage compatible with Amazon S3 cloud storage service
  • Trivy: Kubernetes-native security toolkit
  • Thanos: HA Prometheus setup with long term storage capabilities
  • Falco: Cloud Native Runtime Security
  • Opencost: Cost monitoring for Kubernetes
  • Tekton Pipeline: K8s-style resources for declaring CI/CD pipelines
  • Tekton Triggers: Trigger pipelines from event payloads
  • Tekton dashboard: Web-based UI for Tekton Pipelines and Tekton Triggers
  • Paketo build packs: Cloud Native Buildpack implementations for popular programming language ecosystems
  • Cloudnative-pg: Open source operator designed to manage PostgreSQL workloads
  • Grafana Tempo: High-scale distributed tracing backend
  • OpenTelemetry: Instrument, generate, collect, and export telemetry data to help you analyze your software’s performance and behavior

Catagories​

Otomi contains four catagories of integrated K8s applications:

  • Core applications: applications that are activated by default
  • Shared applications: applications that are shared between teams. Shared applications are user-, and role-aware or not (user is anonymous)
  • Team applications: applications with a dedicated instance per team
  • Optional applications: applications that are optional and can be activated by the platform admin

The following table shows all integrated applications:

ApplicationCoreSharedTeamUser/role-awareOptional
IstioX
Ingress NGINX ControllerX
KnativeX
KeyCloakXX
Prometheus ServerXX
Prometheus kube state metricsXX
AlertmanagerXX
Grafana/LokiXXX
Gatekeeper OperatorX
Hashicorp VaultXXX
HarborXXX
DroneXX
GiteaXX
HttpbinXX
JeagerXX
KialiX
VeleroX
MinioX
OpencostX
Tekton PipelineXXXX
Trivy OperatorX
Cloudnative-pgX

Advanced ingress architecture as its core​

Otomi by default installs and configures an advanced ingress architecture. Ingress for a service can be configured using Otomi Services. The following figure shows the ingress and SSO architecture.

img/ingress-overview

The ingress & SSO architecture overview explained:

  • (optional) an external gateway is used for termination of external traffic (e.g. an Azure Application Gateway or an AWS Application Load Balancer).
  • 2 Ingress NGINX controllers are deployed, one for public access and one for authenticated access.
  • Authenticated (SSO) access is handled by an oauth2 proxy and KeyCloak. The user logs in using the Otomi custom KeyCloak login page.
  • KeyCloak is configured with an external IDP (optional) or uses local accounts. After authentication, KeyCloak provides a normalized JWT token. The JWT token is used by integrated core applications (providing user and role information) and team services configured with SSO
  • 4 Istio (ingress) gateways are provisioned:
  1. a public gateway for routing public (non authenticated traffic to a service)
  2. an authentication gateway to route authenticated traffic to a service
  3. a local gateway (for local cluster routing)
  4. a Knative gateway to route traffic to Knative services
  • For each service a Istio virtual service is configured.
  • One egress gateway is provisioned for all egress traffic (network policies allow all egress traffic).

Otomi Tasks​

Otomi Tasks contains a set of Kubernetes jobs and teh Otomi Operator. The jobs and Operator ensure that the configuration of applications integrated in Otomi are always equal to the desired-state configuration (see Otomi Values). An example: If a team is created via Otomi Console (in combination with Otomi API), Otomi Tasks ensures that a project is created for the new team in Harbor, the access to the project in Harbor is configured, a robot account (that can be used to push images to the project registry) is created and that a pull secret is created in the namespace of the team.

Otomi Tasks is currently used to configure the following applications:

  • KeyCloak
  • Harbor
  • Gitea
  • Drone
  • Otomi (copy-certs and wait-for)

Otomi Clients​

A factory to build and publish openapi clients used in the redkubes/otomi-tasks repo.

Otomi Clients is currently used to generate openapi clients for the following applications:

  • KeyCloak
  • Harbor
  • Gitea

Otomi API​

Otomi API allows for a controlled change of all Otomi Values, based on a configuration scheme and is the brain of Otomi. Otomi API runs as a container on each cluster running.

info

Otomi API is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact Red Kubes for details on support and pricing for a full featured version.

Otomi Console​

Otomi Console is the User Interface of Otomi. Otomi Console communicates with Otomi API for reading and changing Otomi Values configuration. Otomi Console also offers (via the Otomi Apps option) shortcuts to the UI of the various integrated applications.

info

Otomi Console is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact Red Kubes for details on support and pricing for a full featured version.

- +

Otomi Projects

Otomi consists out of the following projects:

Projectopen source
otomi-coreYes
otomi-tasksYes
otomi-clientsYes
otomi-consoleNo
otomi-apiNo

Otomi Core​

Otomi Core contains all the integrated applications and is made available (per release) as a container image.

Otomi Core also contains the source code for Otomi CLI. Otomi CLI can be used for advanced initial configuration (bootstrapping), deployment, sync, push, template validation, and much more.

Integrated K8s applications​

Otomi Core is the heart of Otomi and contains a suite of the following integrated Kubernetes applications:

  • Istio: The service mesh framework with end-to-end transit encryption
  • Keycloak: Identity and access management for modern applications and services
  • Cert Manager - Bring your own wildcard certificate or request one from Let's Encrypt
  • Nginx Ingress Controller: Ingress controller for Kubernetes
  • External DNS: Synchronize exposed ingresses with DNS providers
  • Drone: Continuous integration platform built on Docker
  • Gitea: Self-hosted Git service
  • Velero: Back up and restore your Kubernetes cluster resources and persistent volumes
  • Argo CD: Declarative continuous deployment
  • Knative: Deploy and manage serverless workloads
  • Kaniko: Build container images from a Dockerfile
  • Prometheus: Collecting container application metrics
  • Grafana: Visualize metrics, logs, and traces from multiple sources
  • Grafana Loki: Collecting container application logs
  • Harbor: Container image registry with role-based access control, image scanning, and image signing
  • HashiCorp Vault: Manage Secrets and Protect Sensitive Data
  • OPA/Gatekeeper: Policy-based control for cloud-native environments
  • Jaeger: End-to-end distributed tracing and monitor for complex distributed systems
  • Kiali: Observe Istio service mesh relations and connections
  • Minio: High performance Object Storage compatible with Amazon S3 cloud storage service
  • Trivy: Kubernetes-native security toolkit
  • Thanos: HA Prometheus setup with long term storage capabilities
  • Falco: Cloud Native Runtime Security
  • Opencost: Cost monitoring for Kubernetes
  • Tekton Pipeline: K8s-style resources for declaring CI/CD pipelines
  • Tekton Triggers: Trigger pipelines from event payloads
  • Tekton dashboard: Web-based UI for Tekton Pipelines and Tekton Triggers
  • Paketo build packs: Cloud Native Buildpack implementations for popular programming language ecosystems
  • Cloudnative-pg: Open source operator designed to manage PostgreSQL workloads
  • Grafana Tempo: High-scale distributed tracing backend
  • OpenTelemetry: Instrument, generate, collect, and export telemetry data to help you analyze your software’s performance and behavior

Catagories​

Otomi contains four catagories of integrated K8s applications:

  • Core applications: applications that are activated by default
  • Shared applications: applications that are shared between teams. Shared applications are user-, and role-aware or not (user is anonymous)
  • Team applications: applications with a dedicated instance per team
  • Optional applications: applications that are optional and can be activated by the platform admin

The following table shows all integrated applications:

ApplicationCoreSharedTeamUser/role-awareOptional
IstioX
Ingress NGINX ControllerX
KnativeX
KeyCloakXX
Prometheus ServerXX
Prometheus kube state metricsXX
AlertmanagerXX
Grafana/LokiXXX
Gatekeeper OperatorX
Hashicorp VaultXXX
HarborXXX
DroneXX
GiteaXX
HttpbinXX
JeagerXX
KialiX
VeleroX
MinioX
OpencostX
Tekton PipelineXXXX
Trivy OperatorX
Cloudnative-pgX

Advanced ingress architecture as its core​

Otomi by default installs and configures an advanced ingress architecture. Ingress for a service can be configured using Otomi Services. The following figure shows the ingress and SSO architecture.

img/ingress-overview

The ingress & SSO architecture overview explained:

  • (optional) an external gateway is used for termination of external traffic (e.g. an Azure Application Gateway or an AWS Application Load Balancer).
  • 2 Ingress NGINX controllers are deployed, one for public access and one for authenticated access.
  • Authenticated (SSO) access is handled by an oauth2 proxy and KeyCloak. The user logs in using the Otomi custom KeyCloak login page.
  • KeyCloak is configured with an external IDP (optional) or uses local accounts. After authentication, KeyCloak provides a normalized JWT token. The JWT token is used by integrated core applications (providing user and role information) and team services configured with SSO
  • 4 Istio (ingress) gateways are provisioned:
  1. a public gateway for routing public (non authenticated traffic to a service)
  2. an authentication gateway to route authenticated traffic to a service
  3. a local gateway (for local cluster routing)
  4. a Knative gateway to route traffic to Knative services
  • For each service a Istio virtual service is configured.
  • One egress gateway is provisioned for all egress traffic (network policies allow all egress traffic).

Otomi Tasks​

Otomi Tasks contains a set of Kubernetes jobs and teh Otomi Operator. The jobs and Operator ensure that the configuration of applications integrated in Otomi are always equal to the desired-state configuration (see Otomi Values). An example: If a team is created via Otomi Console (in combination with Otomi API), Otomi Tasks ensures that a project is created for the new team in Harbor, the access to the project in Harbor is configured, a robot account (that can be used to push images to the project registry) is created and that a pull secret is created in the namespace of the team.

Otomi Tasks is currently used to configure the following applications:

  • KeyCloak
  • Harbor
  • Gitea
  • Drone
  • Otomi (copy-certs and wait-for)

Otomi Clients​

A factory to build and publish openapi clients used in the redkubes/otomi-tasks repo.

Otomi Clients is currently used to generate openapi clients for the following applications:

  • KeyCloak
  • Harbor
  • Gitea

Otomi API​

Otomi API allows for a controlled change of all Otomi Values, based on a configuration scheme and is the brain of Otomi. Otomi API runs as a container on each cluster running.

info

Otomi API is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact Red Kubes for details on support and pricing for a full featured version.

Otomi Console​

Otomi Console is the User Interface of Otomi. Otomi Console communicates with Otomi API for reading and changing Otomi Values configuration. Otomi Console also offers (via the Otomi Apps option) shortcuts to the UI of the various integrated applications.

info

Otomi Console is not open source. When installing Otomi, a FREE Community Edition version is installed. Contact Red Kubes for details on support and pricing for a full featured version.

+ \ No newline at end of file diff --git a/product/eula/v1/index.html b/product/eula/v1/index.html index bfe524db3..b5c7ae381 100644 --- a/product/eula/v1/index.html +++ b/product/eula/v1/index.html @@ -14,7 +14,7 @@ - + @@ -23,8 +23,8 @@ This Red Kubes End User Agreement is between the User and Red Kubes and addresses relevant considerations that apply to Red Kubes Products, open source software, and our subscription business model.

1. The Mechanics of the Agreement​

  1. Ordering. The Agreement applies to Red Kubes Products for which you acquire the right to access or use, including Subscriptions, access to Red Kubes Online Properties and other Red Kubes offerings.
  2. Structure. The Agreement consists of two components: (1) the General Terms and (2) the Product Appendices applicable to Your Products. Certain terms are defined in the General Terms or in the Definitions section at the end of the General Terms.

2. License​

  1. Software License. Subject to your ongoing compliance with all the terms and conditions of this Agreement, Red Kubes hereby grants you a non-exclusive, non-sublicensable, non-transferrable, worldwide, revocable license to download and use the Software, specifically the Community Edition, for your own internal business operation only.
  2. License Restrictions. You will not: (a) copy or use the Software in any manner except as expressly permitted in this Agreement; (b) reverse engineer, disassemble, or decompile the Software (except to the extent such restrictions are prohibited by law); (c) alter, modify, enhance or prepare any derivative work from or of the Software; (d) alter or remove any proprietary notices in the Software; or (e) export the Software in violation any export laws or regulations. If you do not comply with the license terms or the foregoing restrictions, Red Kubes may terminate or suspend your license to the Software until you come into compliance with such terms and restrictions. The Software may contain disabling codes that prevent use of the Software outside of the authorized scope and may contain functionality such that the Software reports to Red Kubes certain general metric information about your use of the Software.
  3. Third Party Components and Third Party Software. The Software may include third party software components provided under separate license terms (“Third Party Components”), including open source software from the Otomi Project. Nothing in this Agreement limits your rights to obtain and use the Third Party Components under the separate license terms that are applicable to each Third Party Component. However the Software is made available to you only pursuant to this Agreement. In addition, Red Kubes may in its sole discretion, make available other third party software (“Third Party Software”) embedded in, or otherwise provided with, the Software. Third Party Software is expressly excluded from the defined term “Software” as used throughout this Agreement. Your use of the Third Party Software is subject to the applicable third party license terms as set forth here, and such Third Party Software is not licensed to you under the terms of this Agreement. If you do not agree to abide by the applicable license terms for the Third Party Software, then you may not access or use the Software or the Third Party Software. You are solely and exclusively responsible for determining if you are permitted to use the Third Party Software and you should address any questions in this regard directly to the relevant Third Party Software licensor.

3. Term​

  1. Agreement Term. The Agreement begins on the Effective Date and continues until it is terminated as set forth below.

4. Fees and Payment​

  1. The Software is made available to you under this Agreement free of charge.

5. Termination​

  1. Termination. This Agreement will remain in effect until terminated. You may terminate this Agreement at any time, for any reason or no reason, by ceasing all use of the Software and deleting all copies in your possession or control. Red Kubes may terminate this Agreement at any time, for any reason or no reason, upon notice by any method, including without limitation a post to the web page from which you downloaded the Software or an email sent to an email address you provided when you downloaded the Software.
  2. Effect of Termination; Survival. The termination of this Agreement will not terminate or suspend other provisions of the Agreement.

6. Representations and Warranties​

  1. Red Kubes represents and warrants that (a) it has the authority to enter into this Agreement, and (b) to its knowledge, the Software does not, at the time of delivery to you, include malicious mechanisms or code for the purpose of damaging or corrupting the Software.. User represents and warrants that (a) it has the authority to enter into this Agreement, and (b) its use of Red Kubes Products will comply with all applicable laws, and it will not use the Red Kubes Products for any illegal activity.
  2. To the maximum extent permitted by applicable law and except as expressly provided in section 6.1, the Red Kubes Products are provided ‘ as is’ and without any representations or warranties express or implied, and Red Kubes disclaims all such representations and warranties, including the implied warranties of merchantability, non-infringement, and fitness for a particular purpose, and any warranties implied by the course of dealing of usage of trade. Red Kubes and its suppliers do not represent or warrant that the Red Kubes Products will be uninterrupted, secure, error free, accurate or complete or comply with regulatory requirements, or that Red Kubes will correct all errors. In the event of a breach of the warranties set forts in section 6.1., your exclusive remedy, and Red Kubes’ entire liability, will be the re-performance of re-delivery of the deficient Red Kubes Product, or if Red Kubes cannot substantially correct a breach in a commercially reasonable manner, termination of the relevant Red Kubes Product. .
  3. The Red Kubes Products have not been tested in all situations under which they may be used. Red Kubes will not be liable for the results obtained through use of the Red Kubes Products and you are solely responsible for determining appropriate uses for the Red Kubes Products and for all results of such use. In particular, Red Kubes Products are not specifically designed, manufactured or intended for use in (a) the design, planning, construction, maintenance, control, or direct operation of nuclear facilities, (b) aircraft control, navigation, or communication systems (c) weapons systems, (d) direct life support systems (e) or other similar hazardous environments.

7. Confidentiality​

  1. Recipient (a) may not disclose Confidential Information of a Discloser to any third party unless Discloser approves the disclosure in writing or the disclosure is otherwise permitted under this Section 7; (b) will use the same degree of care to protect Confidential Information of Discloser as it uses to protect its own confidential information of a similar nature, but in no event less than reasonable care; and (c) may disclose Confidential Information of the Discloser only to its employees, Affiliates, agents and contractors with a need to know, and to its auditors and legal counsel, in each case, who are under a written obligation (or other professional obligation) to keep such information confidential using standards of confidentiality no less restrictive than those required by this Section 7. These obligations will continue for a period of two (2) years following initial disclosure of the particular Confidential Information. A Recipient may disclose Confidential Information if it is required to do so by applicable law, regulation or court order but, where legally permissible, will provide advance notice to the Discloser to enable the Discloser to seek a protective order or other similar protection if feasible. “Recipient” is the party receiving Confidential Information under this Agreement. “Discloser” is a party disclosing Confidential Information under this Agreement
  2. Information is not Confidential Information, if: (a) the information is or becomes publicly available other than as a result of the Recipient’s breach of this Agreement, (b) the Recipient, at the time of disclosure, knows or possesses the information without obligation of confidentiality or thereafter obtains the information from a third party not under an obligation of confidentiality; (c) the Recipient independently develops the information without use of the Discloser’s Confidential Information, (d) the information is generally known or easily developed by someone with ordinary skills in the business of the Recipient, or (e) the information is licensed under an Open Source License (as defined by the Open Source Initiative (https://opensource.org/)). 7.3 Confidential Information that is disclosed prior to termination of this Agreement will remain subject to this Agreement for the period set forth above. Upon written request of the Discloser, the Recipient will promptly return or destroy all Confidential Information, except for Confidential Information stored in routine back-up media not accessible during the ordinary course of business.

8. End User Information, Feedback, Reservation of Rights, & Review​

  1. End User Information. If you provide End User Information in connection with your use of or access to Red Kubes Products, you agree that, subject to Section 7, Red Kubes, its Affiliates, and Suppliers may use such End User Information in connection with providing the Red Kubes Products. You agree that your provision (and Red Kubes’ use) of End User Information under this Agreement does not require any additional consents or licenses, will be in compliance with applicable law, and will not violate any intellectual property, proprietary, privacy, or other right of any third party. As between Red Kubes and you, you retain all other rights in and to End User Information.
  2. Feedback. You may be asked to voluntarily provide Red Kubes with Feedback in connection with Red Kubes Products, but have no obligation to do so. If you choose to do so, Red Kubes may use Feedback for any purpose, including incorporating the Feedback into, or using the Feedback to develop and improve Red Kubes Products and other Red Kubes offerings without attribution or compensation. You grant Red Kubes a perpetual and irrevocable license to use all Feedback for any purpose. You agree to provide Feedback to Red Kubes only in compliance with applicable laws and you represent that you have the authority to provide the Feedback and that Feedback will not include proprietary information of a third party.
  3. Reservation of Rights. Red Kubes grants to you only those rights expressly granted in -the Agreement with respect to the Red Kubes Products and reserves all other rights in and to the Red Kubes Products (including all intellectual property rights). Red Kubes may collect and use for any purpose aggregate anonymous benchmark data about your use of the Red Kubes Products. Nothing in this Agreement will limit Red Kubes from providing software, materials, or services for itself or other clients, irrespective of the possible similarity of such software, materials or services to those that might be delivered to you. The terms of Section 7 will not prohibit or restrict either party's right to develop, use or market products or services similar to or competitive with the other party; provided, however, that neither party is relieved of its obligations under this Agreement.

9. Review​

While this Agreement is in effect and for one year thereafter, Red Kubes or its designee, acting in accordance with Section 7, may inspect your facilities and records to verify your compliance with this Agreement. You agree to (a) respond promptly to requests for information, documents and/or records, (b) grant appropriate access for on-site visits in order to verify your compliance, and (c) reasonably cooperate in connection with any such verification. Red Kubes will provide at least ten (10) days prior written notice for any on-site visits, and will conduct onsite visits during regular business hours in a manner that reasonably minimizes interference with your business. If Red Kubes notifies you of any noncompliance, then you will resolve the non-compliance within fifteen (15) days from the date of notice.

10. Limitations​

  1. Disclaimer of damages. To the maximum extent permitted by applicable law, neither party, not its Affiliates, will be liable for any incidental, consequential, special, indirect, exemplary or punitive damages, of for any damages for lost or damaged data, lost profits, lost savings of business or service interruption, even if such party was advised of the possibility of such damages, and regardless of the failure of essential purpose of any limited remedy.
  2. Limitations of liability. To the maximum extent permitted by applicable law, Red Kubes’ and its Affiliates’ total and aggregate liability with respect to any claim relating to or arising out of this Agreement will not exceed ten euros with respect to the particular Red Kubes Product given rise to liability under the most applicable ordering document during the twelve (12) months immediately preceding the first event giving rise to such claim. This limitation applies regardless of the nature of the claim, whether contract, tort (including negligence), statute or other legal theory.
  3. No exclusion or limitation of liability. Notwithstanding any other provision of this Agreement and / or any offer, Red Kubes does not exclude or limit liability for (a) personal injury or death to the extent that such injury or death results from the negligence or willful default of Red Kubes, its agents, Affiliates, or subcontractors; (b) any fraudulent misrepresentation upon which the claiming party can be shown to have relied; or (c) any other liability which is not permissible at law to exclude or limit.

11. Governing Law and Claims.​

The Agreement, and any claim, controversy or dispute related to the Agreement, are governed by and construed in accordance with the Dutch law without giving effect to any conflicts of laws provisions. To the extent permissible, the United Nations Convention on Contracts for the International Sale of Goods will not apply, even if adopted as part of the Dutch law. Any claim, suit, action or proceeding arising out of or relating to this Agreement or its subject matter will be brought exclusively in the courts of the Netherlands and each party irrevocably submits to the exclusive jurisdiction and venue. No claim or action, regardless of form, arising out of this Agreement may be brought by either party more than one (1) year after the party first became aware, or reasonably should have been aware, of the basis for the claim.

12. Miscellaneous​

  1. Notices. Notices must be in English, in writing, and will be deemed given upon receipt, after being sent using a method that provides for positive confirmation of delivery to the address(es) or email address provided by you, including through an automated receipt or by electronic log. Any notice from you to Red Kubes must include a copy sent to: Red Kubes’ email address info@redkubes.com.
  2. Assignment. Either party may upon written notice: (a) assign this Agreement to an Affiliate if the Affiliate is able to satisfy the assigning party’s obligations under the Agreement and the assignment will not affect the non-assigning party’s obligations under the Agreement; and (b) assign this Agreement to a successor or acquirer pursuant to a merger or sale of all or substantially all of such party’s assets. Any other assignment will be deemed void and ineffective without the prior written consent of the other party. Subject to the foregoing, this Agreement will be binding upon and will insure to the benefit of the parties and their respective successors and permitted assigns.
  3. Waiver. A waiver by a party under this Agreement is only valid if in writing and signed by an authorized representative of such party. A delay or failure of a party to exercise any rights under this Agreement will not constitute or be deemed a waiver or forfeiture of such rights.
  4. Independent Contractors. The parties are independent contractors and nothing in this Agreement creates an employment, partnership or agency relationship between the parties or any Affiliate. Each party is solely responsible for supervision, control and payment of its personnel.
  5. Third Party Beneficiaries. This Agreement is binding on the parties to this Agreement and, other than as expressly provided in the Agreement, nothing in this Agreement grants any other person or entity any right, benefit or remedy.
  6. Force Majeure. Neither party is responsible for nonperformance or delay in performance of its obligations due to causes beyond its reasonable control.
  7. Complete Agreement and Order of Precedence. The Agreement represents the complete agreement between the parties with respect to its subject matter and supersedes all prior and contemporaneous agreements and proposals, whether written or oral, with respect to such subject matter. Any terms contained in any other documentation that you deliver to Red Kubes, are void and will not become part of the Agreement or otherwise bind the parties. If there is a conflict between the General Terms and the Product Appendices, the General Terms will control unless otherwise expressly provided in the Product Appendices.
  8. Counterparts. This Agreement may be executed in counterparts, each of which will be deemed an original and all of which will constitute one and the same document. The parties may exchange signature pages by email or electronic signature process and such signatures will be effective to bind the parties to the Agreement.
  9. Severable. If any provision of this Agreement is held by a court of competent jurisdiction to be invalid or unenforceable, the remaining provisions of this Agreement will remain in effect to the greatest extent permitted by law.

13. Definitions​

  1. “Affiliate” means an entity that owns or controls, is owned or controlled by, or is under common control or ownership with a party, where “control” is the possession, direct or indirect, of the power to direct or cause the direction of the management and policies of an entity, whether through ownership of voting securities, by contract or otherwise.
  2. “Business Partner” means a cloud provider, distributor, reseller, OEM or other third party authorized to resell or distribute Red Kubes Products.
  3. “Business Partner order” means an order for a Red Kubes Product placed through a Business Partner.
  4. “End User” or “you” means the person or entity acquiring the right to use or access the Red Kubes Products and which is a party to this Agreement.
  5. “End User Information” means any data, information, software or other materials that you provide to Red Kubes under the Agreement.
  6. “Confidential Information” means information disclosed by the Discloser to the Recipient during the term of the Agreement that (i) is marked confidential; (ii) if disclosed orally, is clearly described as confidential at the time of disclosure and is subsequently set forth in writing, marked confidential, and sent to the Recipient within thirty (30) days following the oral disclosure; or (iii) is of a nature that the Recipient knows is confidential to the Discloser or should reasonably be expected to know is confidential.
  7. “Effective Date” means earliest of (a) the date of the last signature on this Agreement, (b) your online acceptance of the Agreement, and (c) when you first receive access to a Red Kubes Product.
  8. “Feedback” means any ideas, suggestions, proposals or other feedback you may provide regarding Red Kubes Products.
  9. “General Terms” means the terms contained in Sections 1 – 13 of this document.
  10. “Product Appendices” means (a) the Red Kubes Product Appendices that are incorporated into an applicable statement of work.
  11. “Red Kubes Products” means Software, Services, Subscriptions and other Red Kubes branded offerings made available by Red Kubes.
  12. “Software” means Red Kubes branded software that is included in Red Kubes Product offerings.
  13. “Subscription” means a time bound Red Kubes Services offering, other than Professional Services.
  14. “Supplier” means a third party that provides service(s) to Red Kubes in order for Red Kubes to offer Services to its customers and/or Business Partners.
  15. “Your Products” means the Red Kubes Products that you have purchased, licensed, or otherwise acquired the right to access or use.
- +the Agreement with respect to the Red Kubes Products and reserves all other rights in and to the Red Kubes Products (including all intellectual property rights). Red Kubes may collect and use for any purpose aggregate anonymous benchmark data about your use of the Red Kubes Products. Nothing in this Agreement will limit Red Kubes from providing software, materials, or services for itself or other clients, irrespective of the possible similarity of such software, materials or services to those that might be delivered to you. The terms of Section 7 will not prohibit or restrict either party's right to develop, use or market products or services similar to or competitive with the other party; provided, however, that neither party is relieved of its obligations under this Agreement.

9. Review​

While this Agreement is in effect and for one year thereafter, Red Kubes or its designee, acting in accordance with Section 7, may inspect your facilities and records to verify your compliance with this Agreement. You agree to (a) respond promptly to requests for information, documents and/or records, (b) grant appropriate access for on-site visits in order to verify your compliance, and (c) reasonably cooperate in connection with any such verification. Red Kubes will provide at least ten (10) days prior written notice for any on-site visits, and will conduct onsite visits during regular business hours in a manner that reasonably minimizes interference with your business. If Red Kubes notifies you of any noncompliance, then you will resolve the non-compliance within fifteen (15) days from the date of notice.

10. Limitations​

  1. Disclaimer of damages. To the maximum extent permitted by applicable law, neither party, not its Affiliates, will be liable for any incidental, consequential, special, indirect, exemplary or punitive damages, of for any damages for lost or damaged data, lost profits, lost savings of business or service interruption, even if such party was advised of the possibility of such damages, and regardless of the failure of essential purpose of any limited remedy.
  2. Limitations of liability. To the maximum extent permitted by applicable law, Red Kubes’ and its Affiliates’ total and aggregate liability with respect to any claim relating to or arising out of this Agreement will not exceed ten euros with respect to the particular Red Kubes Product given rise to liability under the most applicable ordering document during the twelve (12) months immediately preceding the first event giving rise to such claim. This limitation applies regardless of the nature of the claim, whether contract, tort (including negligence), statute or other legal theory.
  3. No exclusion or limitation of liability. Notwithstanding any other provision of this Agreement and / or any offer, Red Kubes does not exclude or limit liability for (a) personal injury or death to the extent that such injury or death results from the negligence or willful default of Red Kubes, its agents, Affiliates, or subcontractors; (b) any fraudulent misrepresentation upon which the claiming party can be shown to have relied; or (c) any other liability which is not permissible at law to exclude or limit.

11. Governing Law and Claims.​

The Agreement, and any claim, controversy or dispute related to the Agreement, are governed by and construed in accordance with the Dutch law without giving effect to any conflicts of laws provisions. To the extent permissible, the United Nations Convention on Contracts for the International Sale of Goods will not apply, even if adopted as part of the Dutch law. Any claim, suit, action or proceeding arising out of or relating to this Agreement or its subject matter will be brought exclusively in the courts of the Netherlands and each party irrevocably submits to the exclusive jurisdiction and venue. No claim or action, regardless of form, arising out of this Agreement may be brought by either party more than one (1) year after the party first became aware, or reasonably should have been aware, of the basis for the claim.

12. Miscellaneous​

  1. Notices. Notices must be in English, in writing, and will be deemed given upon receipt, after being sent using a method that provides for positive confirmation of delivery to the address(es) or email address provided by you, including through an automated receipt or by electronic log. Any notice from you to Red Kubes must include a copy sent to: Red Kubes’ email address info@redkubes.com.
  2. Assignment. Either party may upon written notice: (a) assign this Agreement to an Affiliate if the Affiliate is able to satisfy the assigning party’s obligations under the Agreement and the assignment will not affect the non-assigning party’s obligations under the Agreement; and (b) assign this Agreement to a successor or acquirer pursuant to a merger or sale of all or substantially all of such party’s assets. Any other assignment will be deemed void and ineffective without the prior written consent of the other party. Subject to the foregoing, this Agreement will be binding upon and will insure to the benefit of the parties and their respective successors and permitted assigns.
  3. Waiver. A waiver by a party under this Agreement is only valid if in writing and signed by an authorized representative of such party. A delay or failure of a party to exercise any rights under this Agreement will not constitute or be deemed a waiver or forfeiture of such rights.
  4. Independent Contractors. The parties are independent contractors and nothing in this Agreement creates an employment, partnership or agency relationship between the parties or any Affiliate. Each party is solely responsible for supervision, control and payment of its personnel.
  5. Third Party Beneficiaries. This Agreement is binding on the parties to this Agreement and, other than as expressly provided in the Agreement, nothing in this Agreement grants any other person or entity any right, benefit or remedy.
  6. Force Majeure. Neither party is responsible for nonperformance or delay in performance of its obligations due to causes beyond its reasonable control.
  7. Complete Agreement and Order of Precedence. The Agreement represents the complete agreement between the parties with respect to its subject matter and supersedes all prior and contemporaneous agreements and proposals, whether written or oral, with respect to such subject matter. Any terms contained in any other documentation that you deliver to Red Kubes, are void and will not become part of the Agreement or otherwise bind the parties. If there is a conflict between the General Terms and the Product Appendices, the General Terms will control unless otherwise expressly provided in the Product Appendices.
  8. Counterparts. This Agreement may be executed in counterparts, each of which will be deemed an original and all of which will constitute one and the same document. The parties may exchange signature pages by email or electronic signature process and such signatures will be effective to bind the parties to the Agreement.
  9. Severable. If any provision of this Agreement is held by a court of competent jurisdiction to be invalid or unenforceable, the remaining provisions of this Agreement will remain in effect to the greatest extent permitted by law.

13. Definitions​

  1. “Affiliate” means an entity that owns or controls, is owned or controlled by, or is under common control or ownership with a party, where “control” is the possession, direct or indirect, of the power to direct or cause the direction of the management and policies of an entity, whether through ownership of voting securities, by contract or otherwise.
  2. “Business Partner” means a cloud provider, distributor, reseller, OEM or other third party authorized to resell or distribute Red Kubes Products.
  3. “Business Partner order” means an order for a Red Kubes Product placed through a Business Partner.
  4. “End User” or “you” means the person or entity acquiring the right to use or access the Red Kubes Products and which is a party to this Agreement.
  5. “End User Information” means any data, information, software or other materials that you provide to Red Kubes under the Agreement.
  6. “Confidential Information” means information disclosed by the Discloser to the Recipient during the term of the Agreement that (i) is marked confidential; (ii) if disclosed orally, is clearly described as confidential at the time of disclosure and is subsequently set forth in writing, marked confidential, and sent to the Recipient within thirty (30) days following the oral disclosure; or (iii) is of a nature that the Recipient knows is confidential to the Discloser or should reasonably be expected to know is confidential.
  7. “Effective Date” means earliest of (a) the date of the last signature on this Agreement, (b) your online acceptance of the Agreement, and (c) when you first receive access to a Red Kubes Product.
  8. “Feedback” means any ideas, suggestions, proposals or other feedback you may provide regarding Red Kubes Products.
  9. “General Terms” means the terms contained in Sections 1 – 13 of this document.
  10. “Product Appendices” means (a) the Red Kubes Product Appendices that are incorporated into an applicable statement of work.
  11. “Red Kubes Products” means Software, Services, Subscriptions and other Red Kubes branded offerings made available by Red Kubes.
  12. “Software” means Red Kubes branded software that is included in Red Kubes Product offerings.
  13. “Subscription” means a time bound Red Kubes Services offering, other than Professional Services.
  14. “Supplier” means a third party that provides service(s) to Red Kubes in order for Red Kubes to offer Services to its customers and/or Business Partners.
  15. “Your Products” means the Red Kubes Products that you have purchased, licensed, or otherwise acquired the right to access or use.
+ \ No newline at end of file diff --git a/product/faq/index.html b/product/faq/index.html index 788f1ed44..de7a1b55d 100644 --- a/product/faq/index.html +++ b/product/faq/index.html @@ -14,13 +14,13 @@ - +
-

FAQ

More about Otomi​

Is Otomi a lightweight version of Rancher or OpenShift

No. Otomi is a pre-configured and curated package of open source projects combined with a self-service portal and requires an existing Kubernetes cluster to be installed on. Otomi can not be used to install a Kubernetes cluster.

Is Otomi some kind of Kubeapps

We can imagine when looking at the list of all pre-configured and ready-to-use apps, you might get the impression that Otomi is some kind of application catalog for Kubernetes. But the opposite is true. When you install Otomi, you will get all of these apps and they’re already configured for you, and they will work out-of-the-box. You can then use the web UI or values repository to adjust the configuration of these apps based on your own requirements.

Otomi itself comes with a Developer Catalog that can be customized do offer custom Helm charts (Golden path Templates) to developers to use.

Do I need to use Gitea for my code repositories?

No. Otomi itself uses Gitea for 2 repositories: the otomi/values and the otomi/charts repositories. otomi/values is used for the "local bookkeeping" of the platform configuration and otomi/charts is used for the Developer Catalog. Using external Git services for these repositories is not supported.

But it is not required to use Gitea for your own code repositories. Yes, Gitea can be used as a Git service for your own code projects, but if you are already using a Git service like Gitlab or GitHub, you are not forced to migrate.

The Build feature in Otomi is configured with credentials for Gitea private repositories, but it is also possible to use public Git repositories, or create a secret for an external Git service and use this secret.

I already have a CI build pipeline. Do I need to use the Build feature in Otomi?

No. If you already have a CI build pipeline you can keep using it. You can choose to push your images to Harbor in Otomi. For this you can download the Docker credentials in Otomi Console.

Do I need to use Harbor?

No, using Harbor is optional. The advantage of using Harbor is that Otomi automatically adds a pull-secret for Harbor to the Team namespace. If you would like to use an external image registry, then you will need to create the pull-secrets yourself.

Setup and Installation​

What are the minimal requirements to install Otomi?

Otomi requires a running Kubernetes cluster of version 1.25 up to 1.27 using a Node pool with at least 12 vCPU and 24 GiB memory, but more is recommended. When using the custom provider (when installing Kubernetes on a unsupported provider), make sure Otomi can create a K8s LoadBalancer Service that is accessible from your machine (but not using 127.0.0.1).

Where can I find all possible configuration options for Otomi?

When installing Otomi with the helm chart you can find its values-schema.json inside, which contains all the possible configuration parameters. It is generated from otomi-core/values-schema.yaml.

Can Otomi be deployed on an existing cluster?

Yes, Otomi can be installed on an existing cluster as long as there are no namespaces that are also used by Otomi. We advise to install Otomi on a Vanilla Kubernetes cluster without any cloud specific add-ons installed.

Can I install Otomi without using a DNS zone?

Yes, using a DNS zone for name resolution is optional (but prefferred). When installing Otomi with minimal values, nip.io is used for name resolution pointing to the public IP of the cloud load balancer.

I don't have an external IdP like Azure AD. Can I still install Otomi?

Yes, using an external IdP like Azure AD is optional. When installing Otomi without OIDC values, Otomi will configure Keycloak as an IdP. You can create users in Keycloak and assign them to the pre-configured roles.

Can I install Otomi on my laptop using Minikube?

Yes. You can use the Otomi custom provider to install Otomi on Kubernetes running on your own hardware, including Minikube. Note that Otomi needs to be able to create a Kubernetes LoadBalancer service and the IP needs to be accessible for pods running in the cluster and for your local browser. 127.0.0.1 can not be used, so running minikube with the Docker provider is not supported. Use the Hyperkit driver instead. Also note that Otomi does not support ARM.

Otomi is a complete platform suite and not a single purpose tool. This is why otomi requires a stable (cloud) infrastructure and sufficient resources. Running Otomi on your laptop is therefor not advised.

Other​

Do you provide commercial support?

Yes, you can contact us for commercial support. Red Kubes is the company behind Otomi.

- +

FAQ

More about Otomi​

Is Otomi a lightweight version of Rancher or OpenShift

No. Otomi is a pre-configured and curated package of open source projects combined with a self-service portal and requires an existing Kubernetes cluster to be installed on. Otomi can not be used to install a Kubernetes cluster.

Is Otomi some kind of Kubeapps

We can imagine when looking at the list of all pre-configured and ready-to-use apps, you might get the impression that Otomi is some kind of application catalog for Kubernetes. But the opposite is true. When you install Otomi, you will get all of these apps and they’re already configured for you, and they will work out-of-the-box. You can then use the web UI or values repository to adjust the configuration of these apps based on your own requirements.

Otomi itself comes with a Developer Catalog that can be customized do offer custom Helm charts (Golden path Templates) to developers to use.

Do I need to use Gitea for my code repositories?

No. Otomi itself uses Gitea for 2 repositories: the otomi/values and the otomi/charts repositories. otomi/values is used for the "local bookkeeping" of the platform configuration and otomi/charts is used for the Developer Catalog. Using external Git services for these repositories is not supported.

But it is not required to use Gitea for your own code repositories. Yes, Gitea can be used as a Git service for your own code projects, but if you are already using a Git service like Gitlab or GitHub, you are not forced to migrate.

The Build feature in Otomi is configured with credentials for Gitea private repositories, but it is also possible to use public Git repositories, or create a secret for an external Git service and use this secret.

I already have a CI build pipeline. Do I need to use the Build feature in Otomi?

No. If you already have a CI build pipeline you can keep using it. You can choose to push your images to Harbor in Otomi. For this you can download the Docker credentials in Otomi Console.

Do I need to use Harbor?

No, using Harbor is optional. The advantage of using Harbor is that Otomi automatically adds a pull-secret for Harbor to the Team namespace. If you would like to use an external image registry, then you will need to create the pull-secrets yourself.

Setup and Installation​

What are the minimal requirements to install Otomi?

Otomi requires a running Kubernetes cluster of version 1.25 up to 1.27 using a Node pool with at least 12 vCPU and 24 GiB memory, but more is recommended. When using the custom provider (when installing Kubernetes on a unsupported provider), make sure Otomi can create a K8s LoadBalancer Service that is accessible from your machine (but not using 127.0.0.1).

Where can I find all possible configuration options for Otomi?

When installing Otomi with the helm chart you can find its values-schema.json inside, which contains all the possible configuration parameters. It is generated from otomi-core/values-schema.yaml.

Can Otomi be deployed on an existing cluster?

Yes, Otomi can be installed on an existing cluster as long as there are no namespaces that are also used by Otomi. We advise to install Otomi on a Vanilla Kubernetes cluster without any cloud specific add-ons installed.

Can I install Otomi without using a DNS zone?

Yes, using a DNS zone for name resolution is optional (but prefferred). When installing Otomi with minimal values, nip.io is used for name resolution pointing to the public IP of the cloud load balancer.

I don't have an external IdP like Azure AD. Can I still install Otomi?

Yes, using an external IdP like Azure AD is optional. When installing Otomi without OIDC values, Otomi will configure Keycloak as an IdP. You can create users in Keycloak and assign them to the pre-configured roles.

Can I install Otomi on my laptop using Minikube?

Yes. You can use the Otomi custom provider to install Otomi on Kubernetes running on your own hardware, including Minikube. Note that Otomi needs to be able to create a Kubernetes LoadBalancer service and the IP needs to be accessible for pods running in the cluster and for your local browser. 127.0.0.1 can not be used, so running minikube with the Docker provider is not supported. Use the Hyperkit driver instead. Also note that Otomi does not support ARM.

Otomi is a complete platform suite and not a single purpose tool. This is why otomi requires a stable (cloud) infrastructure and sufficient resources. Running Otomi on your laptop is therefor not advised.

Other​

Do you provide commercial support?

Yes, you can contact us for commercial support. Red Kubes is the company behind Otomi.

+ \ No newline at end of file diff --git a/product/introduction/index.html b/product/introduction/index.html index 7a615e410..3af5de385 100644 --- a/product/introduction/index.html +++ b/product/introduction/index.html @@ -14,13 +14,13 @@ - +
-

Why Otomi

The vision​

Kubernetes has been called The Operating System of the Cloud. In our opinion, Kubernetes is only the Kernel of the Operating System of the Cloud. The Operating System (or Kubernetes-based Platform) is something you'll need to build yourself. And this is what organizations are now doing when using Kubernetes. All reinventing the wheel.

Building a Kubernetes-based platform requires a huge investment and requires skilled engineers. But why would you invest in building and maintaining a custom platform? Why can't you just install everyting you need to turn Kubernetes into a full platform, just like you can download a Linux distribution?

This is what we indended when we created Otomi. Any infrastructure, any K8s, one install, all the tools you need in an integrated and automated way, easy self-service and everything as code.

What is Otomi?​

Otomi is a self-hosted PaaS and adds developer- and operations-centric tools, automation and self-service on top of Kubernetes offering a multi and hybrid platform experience out-of-the-box. Otomi is placed in the CNCF landscape under the PaaS/Container Service section. Otomi attempts to connect many of the technologies found in the CNCF landscape in a way to provide direct value. No more re-inventing the wheel when building and maintaining your own Kubernetes based platform or bespoke stack.

What is the difference between an IDP and a PaaS?​

An Internal Developer Platform (IDP) consists of many different technologies, glued together to lowers cognitive load on developers without abstracting away context and underlying technologies. An IDP is always custom built.

A PaaS for Kubernetes also lowers cognitive load on developers, but abstracts away most of the underlying technologies. Unlike an IDP, a PaaS can be used almost instantly, just like downloading and using your favourite Linux Distribution. Organizations that use a PaaS instead of building an IDP can enjoy lower upfront costs and huge time savings.

When to build an IDP or use a PaaS?​

Because building an IDP requires a large upfront investment, it’s mostly suitable for large enterprises. For smaller organizations a PaaS can sometimes be far more efficient than building a custom IDP in-house.

Otomi for developers​

Otomi let's developers focus on their application, not on writing Kubernetes manifests! Kubernetes is great for running containers, but it's complex. Wouldn't it be awesome if you didn't need to worry about understanding Kubernetes objects and writing YAML manifests?

This is how Otomi helps developers:

Removing the complexity​

As a Developer, you want to focus on your code and don’t be bothered with Kubernetes internals. With Otomi, you can deploy your apps on Kubernetes without needing to understand or learn Kubernetes. Just build your image, push it to a registry in Otomi and use the Web Console to deploy your app in just a couple of minutes. Otomi makes Kubernetes easy!

All the tools you need​

Otomi provides developers with all the tools they need. After deploying your app you can directly see all the container logs, metrics, status, policy violations and vulnerabilities. Next to access to al kinds of dashboards, you will also get access to Harbor, Tekton and Argo CD.

Best practices​

Otomi offers you the ability to immediately start deploying applications on Kubernetes and configure public exposure. This will give you a jump start to get apps running on Kubernetes. But in time you will probably learn more about Kubernetes and start trying out things yourself. Otomi does not force you to use the Web Console. You can just as easily download the KubeConfig for your team and create and deploy manifests yourself. But Otomi will always force you to adhere to the configured safeguards and best practices.

Self-Serving​

As a developer, you don’t like to go to the Ops team asking for help. Otomi provides full developer self-service. Developers can spin up new virtual environments, download pull secrets, create Kubernetes secrets, build images from source code, deploy workloads and configure public exposure. And all of these features are accessible through just one Web Console. Now you can deliver code completely autonomously.

Otomi for Platform Teams​

If you can’t scale beyond a handful of teams you're going to lose speed. Speed is everything to bring new products and applications to market. No one wants to slow down developers. Empower developers, ensure quality, compliance, and governance, avoid lock-in, and lower the operational burden. These are some of the challenges platform teams have to deal with and where Otomi can help out.

Avoid Cloud Lock-In​

Are you worried that you can’t adopt cloud-native technology without becoming completely reliant on one cloud provider? One way that organizations outsource management for Kubernetes is to use one of the cloud provider’s Kubernetes versions in conjunction with a variety of cloud provider native services. This is often faster than using vanilla Kubernetes and managing integrations and infrastructure in-house, but it also completely locks the organization into the cloud provider and often becomes very expensive.

This approach also takes away the flexibility to change cloud providers in the future while increasing the financial risks. With Otomi, you don’t have to lock yourself into any cloud provider or risk rapidly increasing cloud service bills in order to get the fastest possible platform to deploy containerized applications.

Make Developers Self Serving​

Free developers from worrying about the underlying platform setup while still enforcing standards and best practices so they can focus on delivering code. With Otomi, developers can be fully self-serving. They can spin up new namespaces, get access to all the tools they need, build images from source code, create secrets, deploy workloads, configure public exposure, add service monitors, and much more. And all of these features are accessible through just one web UI.

Platform administrators have access to all the platform applications. Team administrators can create team spaces for development teams and team members can create multiple namespaces within their team space(s).

Lower The Operational Burden​

Choosing the DIY platform engineering approach can be time-consuming and complex. On average, Platform teams need at least 6 months to build an initial setup. And the ongoing maintenance and hardening afterwards can become an operational nightmare. Otomi helps Platform teams to lower the operational burden by taking over the application management of everything running on top of Kubernetes, including the lifecycle management of all the integrated K8s applications.

This enables platform teams to focus on another very important aspect: Kubernetes cluster infrastructure management and cloud security. Now you have time to focus on other important aspects instead of building a custom (internal) developer platform solution.

Prevent Kubernetes Cluster Sprawl​

As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work.

With Otomi you can support (soft) multi-tenancy, allowing multiple development teams to work independently of each other on the same cluster, while sharing all the tools. Now you only have to deploy a single dev or staging cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl.

- +

Why Otomi

The vision​

Kubernetes has been called The Operating System of the Cloud. In our opinion, Kubernetes is only the Kernel of the Operating System of the Cloud. The Operating System (or Kubernetes-based Platform) is something you'll need to build yourself. And this is what organizations are now doing when using Kubernetes. All reinventing the wheel.

Building a Kubernetes-based platform requires a huge investment and requires skilled engineers. But why would you invest in building and maintaining a custom platform? Why can't you just install everyting you need to turn Kubernetes into a full platform, just like you can download a Linux distribution?

This is what we indended when we created Otomi. Any infrastructure, any K8s, one install, all the tools you need in an integrated and automated way, easy self-service and everything as code.

What is Otomi?​

Otomi is a self-hosted PaaS and adds developer- and operations-centric tools, automation and self-service on top of Kubernetes offering a multi and hybrid platform experience out-of-the-box. Otomi is placed in the CNCF landscape under the PaaS/Container Service section. Otomi attempts to connect many of the technologies found in the CNCF landscape in a way to provide direct value. No more re-inventing the wheel when building and maintaining your own Kubernetes based platform or bespoke stack.

What is the difference between an IDP and a PaaS?​

An Internal Developer Platform (IDP) consists of many different technologies, glued together to lowers cognitive load on developers without abstracting away context and underlying technologies. An IDP is always custom built.

A PaaS for Kubernetes also lowers cognitive load on developers, but abstracts away most of the underlying technologies. Unlike an IDP, a PaaS can be used almost instantly, just like downloading and using your favourite Linux Distribution. Organizations that use a PaaS instead of building an IDP can enjoy lower upfront costs and huge time savings.

When to build an IDP or use a PaaS?​

Because building an IDP requires a large upfront investment, it’s mostly suitable for large enterprises. For smaller organizations a PaaS can sometimes be far more efficient than building a custom IDP in-house.

Otomi for developers​

Otomi let's developers focus on their application, not on writing Kubernetes manifests! Kubernetes is great for running containers, but it's complex. Wouldn't it be awesome if you didn't need to worry about understanding Kubernetes objects and writing YAML manifests?

This is how Otomi helps developers:

Removing the complexity​

As a Developer, you want to focus on your code and don’t be bothered with Kubernetes internals. With Otomi, you can deploy your apps on Kubernetes without needing to understand or learn Kubernetes. Just build your image, push it to a registry in Otomi and use the Web Console to deploy your app in just a couple of minutes. Otomi makes Kubernetes easy!

All the tools you need​

Otomi provides developers with all the tools they need. After deploying your app you can directly see all the container logs, metrics, status, policy violations and vulnerabilities. Next to access to al kinds of dashboards, you will also get access to Harbor, Tekton and Argo CD.

Best practices​

Otomi offers you the ability to immediately start deploying applications on Kubernetes and configure public exposure. This will give you a jump start to get apps running on Kubernetes. But in time you will probably learn more about Kubernetes and start trying out things yourself. Otomi does not force you to use the Web Console. You can just as easily download the KubeConfig for your team and create and deploy manifests yourself. But Otomi will always force you to adhere to the configured safeguards and best practices.

Self-Serving​

As a developer, you don’t like to go to the Ops team asking for help. Otomi provides full developer self-service. Developers can spin up new virtual environments, download pull secrets, create Kubernetes secrets, build images from source code, deploy workloads and configure public exposure. And all of these features are accessible through just one Web Console. Now you can deliver code completely autonomously.

Otomi for Platform Teams​

If you can’t scale beyond a handful of teams you're going to lose speed. Speed is everything to bring new products and applications to market. No one wants to slow down developers. Empower developers, ensure quality, compliance, and governance, avoid lock-in, and lower the operational burden. These are some of the challenges platform teams have to deal with and where Otomi can help out.

Avoid Cloud Lock-In​

Are you worried that you can’t adopt cloud-native technology without becoming completely reliant on one cloud provider? One way that organizations outsource management for Kubernetes is to use one of the cloud provider’s Kubernetes versions in conjunction with a variety of cloud provider native services. This is often faster than using vanilla Kubernetes and managing integrations and infrastructure in-house, but it also completely locks the organization into the cloud provider and often becomes very expensive.

This approach also takes away the flexibility to change cloud providers in the future while increasing the financial risks. With Otomi, you don’t have to lock yourself into any cloud provider or risk rapidly increasing cloud service bills in order to get the fastest possible platform to deploy containerized applications.

Make Developers Self Serving​

Free developers from worrying about the underlying platform setup while still enforcing standards and best practices so they can focus on delivering code. With Otomi, developers can be fully self-serving. They can spin up new namespaces, get access to all the tools they need, build images from source code, create secrets, deploy workloads, configure public exposure, add service monitors, and much more. And all of these features are accessible through just one web UI.

Platform administrators have access to all the platform applications. Team administrators can create team spaces for development teams and team members can create multiple namespaces within their team space(s).

Lower The Operational Burden​

Choosing the DIY platform engineering approach can be time-consuming and complex. On average, Platform teams need at least 6 months to build an initial setup. And the ongoing maintenance and hardening afterwards can become an operational nightmare. Otomi helps Platform teams to lower the operational burden by taking over the application management of everything running on top of Kubernetes, including the lifecycle management of all the integrated K8s applications.

This enables platform teams to focus on another very important aspect: Kubernetes cluster infrastructure management and cloud security. Now you have time to focus on other important aspects instead of building a custom (internal) developer platform solution.

Prevent Kubernetes Cluster Sprawl​

As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work.

With Otomi you can support (soft) multi-tenancy, allowing multiple development teams to work independently of each other on the same cluster, while sharing all the tools. Now you only have to deploy a single dev or staging cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl.

+ \ No newline at end of file diff --git a/product/roadmap/index.html b/product/roadmap/index.html index 065d58708..a77d69c1c 100644 --- a/product/roadmap/index.html +++ b/product/roadmap/index.html @@ -14,13 +14,13 @@ - +
-

Roadmap

Supported Kubernetes version​

We are dedicated to maintain support for three different Kubernetes versions within a specific major version of Otomi. Whenever we decide to discontinue support for a particular Kubernetes version, we increment the major version of Otomi.

Otomi VersionSupported Kubernetes versionExpected release date
v1.0.01.25, 1.26, 1.272023-09-28
v2.0.01.25, 1.26, 1.272023-11-28
v3.0.01.26, 1.27, 1.282024-03-28

2023 Q4​

  • Provide a developer catalog in Gitea ✅
  • Migrate platform pipeline from Drone to Tekton ✅
  • Implement status indicators within Otomi Console to keep Team users informed about the status of various components, including Build processes, Workload management, and Service availability ✅
  • Add Team and Platform Dashboards to provide an overview of team resource status using Prometheus metrics ✅
  • Leverage Argo CD to deploy Otomi apps and Teams ✅
  • Quality assurance cluster for continuous Otomi hardening and performance testing ✅
  • Provide UI interface for adding Helm charts to developer catalog in Gitea ✅

2024 Q1​

  • Add the option to add charts from artifacthub to the Catalog 🔄
  • Implement a new secret management solution (as a replacement for Hashicorp Vault) 🔄
  • Harden the Istio service mesh configuration
  • Implement Gitea with a database managed by the CloudNativePG operator

2024 Q2​

  • Enhance network policies across the platform
  • Establish separate Kubernetes namespaces for Team Applications
  • Ensure Otomi's NSA and CISA compliance
  • Enable user configurable storage classes
  • Provide disaster recovery procedures for Otomi core applications, such as Gitea, Keycloak and Harbor

After Q2 2024​

After Q2 2024 we have the following goals:

  • Make Otomi more plugable by enabling users to bring their own platform apps
  • Migrate to ambient mesh using eBPF
  • Remove platform app forms in favor of generated values that can be customized in an editor
- +

Roadmap

Supported Kubernetes version​

We are dedicated to maintain support for three different Kubernetes versions within a specific major version of Otomi. Whenever we decide to discontinue support for a particular Kubernetes version, we increment the major version of Otomi.

Otomi VersionSupported Kubernetes versionExpected release date
v1.0.01.25, 1.26, 1.272023-09-28
v2.0.01.25, 1.26, 1.272023-11-28
v3.0.01.26, 1.27, 1.282024-03-28

2023 Q4​

  • Provide a developer catalog in Gitea ✅
  • Migrate platform pipeline from Drone to Tekton ✅
  • Implement status indicators within Otomi Console to keep Team users informed about the status of various components, including Build processes, Workload management, and Service availability ✅
  • Add Team and Platform Dashboards to provide an overview of team resource status using Prometheus metrics ✅
  • Leverage Argo CD to deploy Otomi apps and Teams ✅
  • Quality assurance cluster for continuous Otomi hardening and performance testing ✅
  • Provide UI interface for adding Helm charts to developer catalog in Gitea ✅

2024 Q1​

  • Add the option to add charts from artifacthub to the Catalog 🔄
  • Implement a new secret management solution (as a replacement for Hashicorp Vault) 🔄
  • Harden the Istio service mesh configuration
  • Implement Gitea with a database managed by the CloudNativePG operator

2024 Q2​

  • Enhance network policies across the platform
  • Establish separate Kubernetes namespaces for Team Applications
  • Ensure Otomi's NSA and CISA compliance
  • Enable user configurable storage classes
  • Provide disaster recovery procedures for Otomi core applications, such as Gitea, Keycloak and Harbor

After Q2 2024​

After Q2 2024 we have the following goals:

  • Make Otomi more plugable by enabling users to bring their own platform apps
  • Migrate to ambient mesh using eBPF
  • Remove platform app forms in favor of generated values that can be customized in an editor
+ \ No newline at end of file diff --git a/product/use-cases/adoption-framework/index.html b/product/use-cases/adoption-framework/index.html index 5ee5b1958..510e5b98d 100644 --- a/product/use-cases/adoption-framework/index.html +++ b/product/use-cases/adoption-framework/index.html @@ -14,7 +14,7 @@ - + @@ -24,8 +24,8 @@ As mentioned above, a migration to Kubernetes can happen more quickly with the help of an adoption framework. Preparation time is significantly reduced. Creating a compliant landigzone for Kubernetes can take up to 12 months (or even more) of work (if you have the required knowledge onboard). This time can be cut down to days with the use of Otomi, resulting in considerable cost savings as well as a shorter time-to-market for new applications and more efficiently DevOps processes. Another key feature inherent in Otomi as an adoption framework is scalability, as it is easy to expand to new environments. It allows the development of standard profiles easily for new Kubernetes clusters in any cloud.

  • Security And Compliance Thanks to guardrails, compliance is an integral part of Otomi, meaning developers and engineers can safely operate containerized workloads on Kubernetes and in observance of compliance regulations. What’s more, organizations don’t spend that much time implementing complex configurations with the risk of technical debt. This especially applies to the operational phase. But it doesn’t stop with a one-off setting of the environment. It is also about keeping all environments up to date in an ongoing and consistent way.

  • A Better Understanding Of Costs Organizations quickly lose control of their engineering expenses because they don’t have a clear overview of the technologies being used and their costs. Otomi reduces unexpected and unnecessary expenses.

  • Standardized For Multi-Tenancy -In a multi-tenant architecture, standardizing tenancy allows you to enforce policies to a group of users. It helps you set up different security profiles and provide access to shared tools with users having specific privileges.

    • What are the capabilities of an adoption framework for Kubernetes?​

    The following picture shows all the required capabilities for a Kubernetes adoption framework, which are all incorporated into Otomi:

    capabilities

    - +In a multi-tenant architecture, standardizing tenancy allows you to enforce policies to a group of users. It helps you set up different security profiles and provide access to shared tools with users having specific privileges.

    What are the capabilities of an adoption framework for Kubernetes?​

    The following picture shows all the required capabilities for a Kubernetes adoption framework, which are all incorporated into Otomi:

    capabilities

    + \ No newline at end of file diff --git a/product/use-cases/ci-cd/index.html b/product/use-cases/ci-cd/index.html index 331cbb1ff..34abd1c91 100644 --- a/product/use-cases/ci-cd/index.html +++ b/product/use-cases/ci-cd/index.html @@ -14,13 +14,13 @@ - +
    -

    CI/CD

    Introduction​

    Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. The integrated tools mainly focus on Continuous Deployment (to automatically deploy code changes after the build stage) and on all runtime controls. When using Otomi, we advice to setup a seprate CI environment (using specialized CI tools like GitHub Actions or CircleCI) where artifacts (images) are build and then pushed to an image registry (like Harbor provided by Otomi). But with integrated tools like Gitea and Tekton, Otomi can in some cases also be used for Continuous Integration (CI). This can be especially interesting in greenfield environments (where there is (not yet) a full CI toolset implemented) or in isolated environments (where developers don't have access to cloud CI services).

    CI with Otomi​

    Users on the platform can get access to an organization in Gitea. See here for a full list of all Gitea features and a comparison with other self-hosted Git solutions.

    Otomi also includes Tekton pipelines. Tekton is used for the build feature in Otomi. The build feature can be used to build images from source using Kaniko (when there is a Docker file), or Buildpacks. To use the build feature, source code needs to be in a private Gitea repo, or in a public git repo. Other private repo's can also be replicated to Gitea.

    CD with Otomi​

    The most common workflow when using Otomi starts when an artifact (image) has been build. Using the workloads feature in Otomi, images can be deployed using a Helm chart from the Developer Catalog.

    Otomi uses the otomi/charts repository in Gitea that contains a library of curated Helm charts that are offered as a quick start. The quick start Helm charts can be adjusted or replaced by your custom (Golden path) Helm charts.

    When a workload specification (a combination of a Helm chart with custom values) has been created, Otomi automatically creates an Argo CD applicationset that deploys the configured chart. A workload can also be configured with the Argo CD Image Updater that can check for new versions of images that are deployed with by the workload and then automatically update to the latest allowed version. The Argo CD Image Updater is only supported in combination with Otomi workloads and images stored in Harbor.

    - +

    CI/CD

    Introduction​

    Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. The integrated tools mainly focus on Continuous Deployment (to automatically deploy code changes after the build stage) and on all runtime controls. When using Otomi, we advice to setup a seprate CI environment (using specialized CI tools like GitHub Actions or CircleCI) where artifacts (images) are build and then pushed to an image registry (like Harbor provided by Otomi). But with integrated tools like Gitea and Tekton, Otomi can in some cases also be used for Continuous Integration (CI). This can be especially interesting in greenfield environments (where there is (not yet) a full CI toolset implemented) or in isolated environments (where developers don't have access to cloud CI services).

    CI with Otomi​

    Users on the platform can get access to an organization in Gitea. See here for a full list of all Gitea features and a comparison with other self-hosted Git solutions.

    Otomi also includes Tekton pipelines. Tekton is used for the build feature in Otomi. The build feature can be used to build images from source using Kaniko (when there is a Docker file), or Buildpacks. To use the build feature, source code needs to be in a private Gitea repo, or in a public git repo. Other private repo's can also be replicated to Gitea.

    CD with Otomi​

    The most common workflow when using Otomi starts when an artifact (image) has been build. Using the workloads feature in Otomi, images can be deployed using a Helm chart from the Developer Catalog.

    Otomi uses the otomi/charts repository in Gitea that contains a library of curated Helm charts that are offered as a quick start. The quick start Helm charts can be adjusted or replaced by your custom (Golden path) Helm charts.

    When a workload specification (a combination of a Helm chart with custom values) has been created, Otomi automatically creates an Argo CD applicationset that deploys the configured chart. A workload can also be configured with the Argo CD Image Updater that can check for new versions of images that are deployed with by the workload and then automatically update to the latest allowed version. The Argo CD Image Updater is only supported in combination with Otomi workloads and images stored in Harbor.

    + \ No newline at end of file diff --git a/product/use-cases/edge/index.html b/product/use-cases/edge/index.html index 59e4b0f08..48a4a9a2d 100644 --- a/product/use-cases/edge/index.html +++ b/product/use-cases/edge/index.html @@ -14,13 +14,13 @@ - +
    -

    Otomi at the edge

    Introduction​

    Edge computing is an approach where you run applications as close as possible to its data sources or end users. One of the benefits is improved response times.

    However, managing edge applications using Kubernetes comes with challenges, like:

    • Deploy and update applications consistently accross multiple clusters
    • Manage the run-time specifications for the applications like ingress, certificates, DNS, network policies, etc.
    • Lifecycle management of all supporting tools
    • Using managed Kubernetes services in different clouds/infrastructures

    How Otomi supports edge computing using Kubernetes​

    One of the benefits of Otomi is that everything managed by Otomi can be specified in a single values file. This enables you to not only define the applications workloads that need to be running on the cluster, but also all the required tools and configuration to support and secure the workloads.

    Let's explain this with an example:

    Suppose you have 2 application workloads that you would like to run on multiple Kubernetes clusters in multiple geographic regions, using different public cloud providers (AWS, Azure, GCP) and different Kubernetes versions (1.22 and 1.23). Next to the 2 workloads, you also would like to use Istio for mTLS, cert-manager for certificates, ingress/egress network policies for isolation and HTTP response headers. Because you can not afford using L7 load balancers with WAF features in the different clouds, you would like to implement Nginx ingress with Modsecurity and OWASP filtering. The following picture shows the desired situation:

    edge

    Read this how-to to learn more about installing Otomi at the edge.

    - +

    Otomi at the edge

    Introduction​

    Edge computing is an approach where you run applications as close as possible to its data sources or end users. One of the benefits is improved response times.

    However, managing edge applications using Kubernetes comes with challenges, like:

    • Deploy and update applications consistently accross multiple clusters
    • Manage the run-time specifications for the applications like ingress, certificates, DNS, network policies, etc.
    • Lifecycle management of all supporting tools
    • Using managed Kubernetes services in different clouds/infrastructures

    How Otomi supports edge computing using Kubernetes​

    One of the benefits of Otomi is that everything managed by Otomi can be specified in a single values file. This enables you to not only define the applications workloads that need to be running on the cluster, but also all the required tools and configuration to support and secure the workloads.

    Let's explain this with an example:

    Suppose you have 2 application workloads that you would like to run on multiple Kubernetes clusters in multiple geographic regions, using different public cloud providers (AWS, Azure, GCP) and different Kubernetes versions (1.22 and 1.23). Next to the 2 workloads, you also would like to use Istio for mTLS, cert-manager for certificates, ingress/egress network policies for isolation and HTTP response headers. Because you can not afford using L7 load balancers with WAF features in the different clouds, you would like to implement Nginx ingress with Modsecurity and OWASP filtering. The following picture shows the desired situation:

    edge

    Read this how-to to learn more about installing Otomi at the edge.

    + \ No newline at end of file diff --git a/product/use-cases/multi-cluster/index.html b/product/use-cases/multi-cluster/index.html index d3ad0b941..9f80d0196 100644 --- a/product/use-cases/multi-cluster/index.html +++ b/product/use-cases/multi-cluster/index.html @@ -14,13 +14,13 @@ - +
    -

    Multi-cluster observability

    Introduction​

    Using multiple Kubernetes clusters can have advantages based on your requirements. Some of the benefits of running multiple Kubernetes clusters are:

    • High availability: When one cluster fails, the other cluster(s) can take the load. Losing one cluster when your applications are appropriately spread across several other clusters is much better than losing a single cluster with everything on it
    • Better end user experience: Splitting workloads can improve performance and reduce latency by providing users with a geographically close environment
    • Separate development and production clusters to reduce the risk of being served beta or non-production code versions

    But from a technical perspective, managing multiple Kubernetes clusters is more complex than managing a single cluster. For effective multi-cluster management, a “single pane of glass” with centralized real-time monitoring, time series comparisons across and within clusters and high availability is essential for teams operating with multiple clusters and multiple providers.

    Multi-cluster observability with Otomi​

    The following image shows a multi-cluster observability setup using Otomi:

    multi-cluster

    1. Aggregation of metrics from workload clusters for Prometheus high availability and single pane of glass
    2. Multi-cluster log aggregation
    3. Preconfigured multi-cluster dashboards
    4. Multi-cluster alerting

    This multi-cluster setup can be expanded with:

    • Running Harbor on the management cluster to provide image and chart registries for the workload clusters
    • Replicate workload cluster Git repositories to the management cluster Git repository
    • Deploy multiple application clusters based on a single cluster profile
    - +

    Multi-cluster observability

    Introduction​

    Using multiple Kubernetes clusters can have advantages based on your requirements. Some of the benefits of running multiple Kubernetes clusters are:

    • High availability: When one cluster fails, the other cluster(s) can take the load. Losing one cluster when your applications are appropriately spread across several other clusters is much better than losing a single cluster with everything on it
    • Better end user experience: Splitting workloads can improve performance and reduce latency by providing users with a geographically close environment
    • Separate development and production clusters to reduce the risk of being served beta or non-production code versions

    But from a technical perspective, managing multiple Kubernetes clusters is more complex than managing a single cluster. For effective multi-cluster management, a “single pane of glass” with centralized real-time monitoring, time series comparisons across and within clusters and high availability is essential for teams operating with multiple clusters and multiple providers.

    Multi-cluster observability with Otomi​

    The following image shows a multi-cluster observability setup using Otomi:

    multi-cluster

    1. Aggregation of metrics from workload clusters for Prometheus high availability and single pane of glass
    2. Multi-cluster log aggregation
    3. Preconfigured multi-cluster dashboards
    4. Multi-cluster alerting

    This multi-cluster setup can be expanded with:

    • Running Harbor on the management cluster to provide image and chart registries for the workload clusters
    • Replicate workload cluster Git repositories to the management cluster Git repository
    • Deploy multiple application clusters based on a single cluster profile
    + \ No newline at end of file diff --git a/product/use-cases/multi-tenancy/index.html b/product/use-cases/multi-tenancy/index.html index d081cd488..f238217d2 100644 --- a/product/use-cases/multi-tenancy/index.html +++ b/product/use-cases/multi-tenancy/index.html @@ -14,13 +14,13 @@ - +
    -

    Multi-tenancy

    Introduction​

    Multi-tenant Kubernetes clusters are shared by multiple users and/or workloads which are referred to as "tenants". Operators most commonly implement resource isolation in Kubernetes, using namespaces and resource quota.

    The most common use cases for implementing multi-tenancy are:

    Probably the most known tools to implement multi-tenancy are Capsule and Kiosk. But these tools only implement multi-tenancy on cluster API level. What they don't offer is multi-tenant and role based access to shared tools on the cluster like Harbor, Vault, Git, and Argo CD. They also don't provide isolation for container logs and custom metrics.

    So what if you would like to offer teams or customers not only access to the Kubernetes API, but also to (automatically provisioned) access to a Git repo, a private docker registry, a space in Vault to create and manage secrets, Argo CD, a private Prometheus instance, isolated log aggregation? This is where Otomi steps in.

    Multi-tenancy in Otomi​

    Otomi goes a step higher up in the stack. Otomi does not only provide multi-tenancy on the K8s API level, but also for shared tools on the cluster.

    multi-tenancy

    When multi-tenancy in Otomi is activated (which is optional), Otomi will support the following features:

    1. Teams are provided with a dedicated Prometheus instance for custom metrics (for metrics that should not be accessible for other tenants)
    2. Teams are provided with a dedicated Grafana instance configured with authorization, allowing only authenticated tenant members to access tenant dashboards
    3. Container logs are separated in Loki combined with authorization, allowing only authenticated tenant members access to the tenants container logs
    4. When Harbor is enabled, tenants will get access to a tenant project, allowing only authenticated tenant members to access tenant registries
    5. When Vault is enabled, tenant will get access to a space in Vault, allowing only authenticated tenant members access to tenant secrets
    6. When ArgoCD is enabled, tenants can only see the tenants ArgoCD applications created by Otomi
    7. Tenants will get access to Gitea and can create their own Git repositories
    8. Tenant namespaces are by default isolated for ingress and egress network traffic
    9. Tenants can allow other tenants to access their services
    10. Tenant services that are publicly exposed can be configured with OIDC, only allowing tenant members to access the exposed services

    Why multi-tenancy in Otomi?​

    Prevent cluster sprawl​

    As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work.

    With Otomi you can support multi-tenancy, allowing multiple tenants (like multiple development teams) to work independently on the same cluster, while sharing all the tools. Now you only have to deploy a single development cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl.

    Fast onboarding of multiple tenants​

    When a new project starts, or when a new development team would like to start using Kubernetes, onboarding usually takes a lot of time. It's not only about providing development teams access to a Kubernetes namespace. No, developers also need access to an image registry, container logs, container metrics, alerts, secrets stores, container vulnerability reports and policy compliance reports.

    With Otomi you can onboard development teams (tenants) in just a couple of minutes, allowing them to login to the self-service portal and:

    • Get access to a private image registry
    • Download the Docker login credentials to get access to their private image registry
    • Build OCI-compliant images from application code
    • Deploy images (stored in the private registry) using the Otomi workloads feature
    • Get access to pre-configured dashboards to see container metrics, policy violations, detected threads in containers and detected vulnerabilities in containers
    • Configure ingress and network policies
    • Configure HTTP response headers
    • Configure CNAMEs
    • Get access to Vault to create and manage secrets
    • Use secrets for ingress or workloads

    When a team already has a code repo with a Dockderfile, they can build, deploy and expose this app within minutes after they have been onboarded onto the platform.

    - +

    Multi-tenancy

    Introduction​

    Multi-tenant Kubernetes clusters are shared by multiple users and/or workloads which are referred to as "tenants". Operators most commonly implement resource isolation in Kubernetes, using namespaces and resource quota.

    The most common use cases for implementing multi-tenancy are:

    Probably the most known tools to implement multi-tenancy are Capsule and Kiosk. But these tools only implement multi-tenancy on cluster API level. What they don't offer is multi-tenant and role based access to shared tools on the cluster like Harbor, Vault, Git, and Argo CD. They also don't provide isolation for container logs and custom metrics.

    So what if you would like to offer teams or customers not only access to the Kubernetes API, but also to (automatically provisioned) access to a Git repo, a private docker registry, a space in Vault to create and manage secrets, Argo CD, a private Prometheus instance, isolated log aggregation? This is where Otomi steps in.

    Multi-tenancy in Otomi​

    Otomi goes a step higher up in the stack. Otomi does not only provide multi-tenancy on the K8s API level, but also for shared tools on the cluster.

    multi-tenancy

    When multi-tenancy in Otomi is activated (which is optional), Otomi will support the following features:

    1. Teams are provided with a dedicated Prometheus instance for custom metrics (for metrics that should not be accessible for other tenants)
    2. Teams are provided with a dedicated Grafana instance configured with authorization, allowing only authenticated tenant members to access tenant dashboards
    3. Container logs are separated in Loki combined with authorization, allowing only authenticated tenant members access to the tenants container logs
    4. When Harbor is enabled, tenants will get access to a tenant project, allowing only authenticated tenant members to access tenant registries
    5. When Vault is enabled, tenant will get access to a space in Vault, allowing only authenticated tenant members access to tenant secrets
    6. When ArgoCD is enabled, tenants can only see the tenants ArgoCD applications created by Otomi
    7. Tenants will get access to Gitea and can create their own Git repositories
    8. Tenant namespaces are by default isolated for ingress and egress network traffic
    9. Tenants can allow other tenants to access their services
    10. Tenant services that are publicly exposed can be configured with OIDC, only allowing tenant members to access the exposed services

    Why multi-tenancy in Otomi?​

    Prevent cluster sprawl​

    As companies look to further harness the power of cloud-native, they are adopting container technologies at rapid speed, increasing the number of clusters and workloads. As the number of Kubernetes clusters grows, this is creating increased work for Platform teams. When it comes to patching security vulnerabilities or upgrading clusters, teams are doing five times the amount of work.

    With Otomi you can support multi-tenancy, allowing multiple tenants (like multiple development teams) to work independently on the same cluster, while sharing all the tools. Now you only have to deploy a single development cluster to support multiple development teams. This prevents you from Kubernetes cluster sprawl.

    Fast onboarding of multiple tenants​

    When a new project starts, or when a new development team would like to start using Kubernetes, onboarding usually takes a lot of time. It's not only about providing development teams access to a Kubernetes namespace. No, developers also need access to an image registry, container logs, container metrics, alerts, secrets stores, container vulnerability reports and policy compliance reports.

    With Otomi you can onboard development teams (tenants) in just a couple of minutes, allowing them to login to the self-service portal and:

    • Get access to a private image registry
    • Download the Docker login credentials to get access to their private image registry
    • Build OCI-compliant images from application code
    • Deploy images (stored in the private registry) using the Otomi workloads feature
    • Get access to pre-configured dashboards to see container metrics, policy violations, detected threads in containers and detected vulnerabilities in containers
    • Configure ingress and network policies
    • Configure HTTP response headers
    • Configure CNAMEs
    • Get access to Vault to create and manage secrets
    • Use secrets for ingress or workloads

    When a team already has a code repo with a Dockderfile, they can build, deploy and expose this app within minutes after they have been onboarded onto the platform.

    + \ No newline at end of file diff --git a/product/use-cases/overview/index.html b/product/use-cases/overview/index.html index 6eab7a202..d6c135dd1 100644 --- a/product/use-cases/overview/index.html +++ b/product/use-cases/overview/index.html @@ -14,13 +14,13 @@ - +
    -

    Use cases overview

    Introduction​

    Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. It contains a complete suite of pre-configured tools and guardrails to run containerized applications securely on any Kubernetes cluster in any cloud. In this section we'll dive a little deeper into some of the use cases Otomi supports.

    Make sure everything is ready to get started

    Adoption framework for Kubernetes​

    Use Otomi as an adoption framework to support migration to Kubernetes in an efficient and streamlined way.

    Multi-tenancy​

    Share a Kubernetes cluster and all the integrated tools with multiple tenants.

    Serverless​

    A landing zone for serverless applications.

    CD/CD​

    Setup CI and CD capabilities.

    - +

    Use cases overview

    Introduction​

    Otomi adds developer- and operations-centric tools, automation and self-service on top of Kubernetes. It contains a complete suite of pre-configured tools and guardrails to run containerized applications securely on any Kubernetes cluster in any cloud. In this section we'll dive a little deeper into some of the use cases Otomi supports.

    Make sure everything is ready to get started

    Adoption framework for Kubernetes​

    Use Otomi as an adoption framework to support migration to Kubernetes in an efficient and streamlined way.

    Multi-tenancy​

    Share a Kubernetes cluster and all the integrated tools with multiple tenants.

    Serverless​

    A landing zone for serverless applications.

    CD/CD​

    Setup CI and CD capabilities.

    + \ No newline at end of file diff --git a/product/use-cases/serverless/index.html b/product/use-cases/serverless/index.html index 7a945df0a..910ced88c 100644 --- a/product/use-cases/serverless/index.html +++ b/product/use-cases/serverless/index.html @@ -14,13 +14,13 @@ - +
    -

    Serverless

    Introduction​

    Knative is a platform that provides tools for deploying, running, and managing serverless cloud-native applications to Kubernetes. Knative brings together the scalability of Kubernetes and ease of development of serverless applications, giving you more control over the resources, and allowing you to focus on the application without worrying about the infrastructure.

    Otomi includes Knative Serving as an optional tool. Otomi installs and configures the correct version of Knative based on the used Kubernetes version and integrates Knative into the Otomi ingress architecture. All you need to do after activating Knative is to deploy a Knative service.

    Creating Knative services​

    There are 3 ways to deploy Knative serverless workloads in Otomi:

    1. Create a raw Knative service manifest and add it to the teams -argocd repository
    2. Create a Otomi serverless workload
    3. Create a Otomi workload with a custom (BYO) Helm chart

    Migrating Lambda functions to Knative​

    A great way to migrate AWS Lambda functions to Kubernetes/Knative is to use Triggermesh KLR. KLR (pronounced clear) are Tekton Tasks that can be used to run an AWS Lambda function in a Kubernetes cluster installed with Knative.

    Steps:

    1. Activate Knative and Argo CD in Otomi
    2. Create a Dockerfile, extracting the desired runtime
    3. Build and push the image (to the private repository in Harbor)
    4. Create a Knative service using the Otomi workload feature
    5. Expose the service publicly using the Otomi services feature
    - +

    Serverless

    Introduction​

    Knative is a platform that provides tools for deploying, running, and managing serverless cloud-native applications to Kubernetes. Knative brings together the scalability of Kubernetes and ease of development of serverless applications, giving you more control over the resources, and allowing you to focus on the application without worrying about the infrastructure.

    Otomi includes Knative Serving as an optional tool. Otomi installs and configures the correct version of Knative based on the used Kubernetes version and integrates Knative into the Otomi ingress architecture. All you need to do after activating Knative is to deploy a Knative service.

    Creating Knative services​

    There are 3 ways to deploy Knative serverless workloads in Otomi:

    1. Create a raw Knative service manifest and add it to the teams -argocd repository
    2. Create a Otomi serverless workload
    3. Create a Otomi workload with a custom (BYO) Helm chart

    Migrating Lambda functions to Knative​

    A great way to migrate AWS Lambda functions to Kubernetes/Knative is to use Triggermesh KLR. KLR (pronounced clear) are Tekton Tasks that can be used to run an AWS Lambda function in a Kubernetes cluster installed with Knative.

    Steps:

    1. Activate Knative and Argo CD in Otomi
    2. Create a Dockerfile, extracting the desired runtime
    3. Build and push the image (to the private repository in Harbor)
    4. Create a Knative service using the Otomi workload feature
    5. Expose the service publicly using the Otomi services feature
    + \ No newline at end of file diff --git a/search/index.html b/search/index.html index 25a85ce03..517dce9e2 100644 --- a/search/index.html +++ b/search/index.html @@ -14,13 +14,13 @@ - +

    Search the documentation

    - + \ No newline at end of file