You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+311
Original file line number
Diff line number
Diff line change
@@ -10,11 +10,322 @@ CNO is an open source platform to onboard easily and securely development teams
10
10
*[Tutorials](#Tutorials)
11
11
12
12
# Concept
13
+
*[CNO - Onboarding](#CNO-Onboarding)
14
+
*[CNO - CD](#CNO-CD)
15
+
*[CNO - HUB](#CNO-HUB)
16
+
*[CNO - Secure](#CNO-Secure)
17
+
18
+
## **CNO - Onboarding**
19
+
The introduction of new technology is not easy in large companies. Sometimes, companies struggle a lot to align the business side especially with adoption of complex technology like Kubernetes.
20
+
21
+
**CNO** helps you to build the best adoption program that minimizes resistance and **aligns cloud-native technology with Business.**
22
+
23
+
CNO is designed to be the **best Kubernetes adoption framework** for your entire organization. It effectively combines three key elements; the best onboarding experience for your teams, a reliable and consistent continuous deployment of your applications to market and finally, the involvement of security during onboarding and the continuous deployment of the applications.
24
+
25
+
26
+
27
+
## Project and Teams Onboarding
28
+
The Onboarding feature is a key element of your Kubernetes adoption process. It will be much easier for the IT Teams to onboard organizational teams and projects within the CNO platform.
29
+
30
+
From CNO UI, your entire organization can be onboarded into different teams working on specific projects.
31
+
32
+
33
+
34
+
* Deploy environments or Kubernetes multicluster namespaces for your applications
35
+
* Enforce Multitenancy across your clusters
36
+
* Define Resources Requests of a project like CPU, Memory or Storage
37
+
* Onboard your organization tenants
38
+
* Assign roles to each team member of the project
39
+
40
+
### **CNO environments or Kubernetes Multi-cluster namespaces**
41
+
CNO supports all Kubernetes platforms from a single console like Kubernetes Vanilla, Distributions like Openshift, Tanzu, Rancher, etc.. and all cloud providers Kubernetes services (AKS, EKS and GKE).
42
+
In one project, you can define your own environnements, e.g. Dev, Staging, Production or any you want.
43
+
44
+
CNO brings here an interesting feature called **Multi-cluster namespaces** that allows you to create your environments or namespaces without taking consideration of the underlying cluster ( Edges, On premises or Public Cloud). best For example, you can create a Dev environment on AWS, a Staging environment on OpenShift and a Production environment on Kubernetes Vanilla located in your own datacenter.
45
+
46
+
### **Teams or Organization tenants Onboarding**
47
+
During the onboarding phase, you can define several tenants into CNO accordingly to your organization hierarchy. These tenants can represent a group of users that has access to a Project and a subset of cluster resources. Each tenant is composed of a Project Owner and his team's members.
48
+
49
+
* The project Owner is responsible for a project and the role assignment to specific users.
50
+
* Team members of a project can be Administrator, Developer or Viewer.
51
+
* Administrators can centralize the management of Kubernetes clusters.
52
+
* Developers can set up their environment and deploy their applications without knowing any cloud providers or any Kubernetes platform.
53
+
* Viewer' role can be assigned to Auditors that have only read-only permissions.
54
+
55
+
56
+
## Multi Tenancy Enforcement
57
+
Kubernetes does not bring by default multitenancy feature. With CNO, you can configure Multitenancy across your different projects and teams.
Several tenants each Project Owner in the company can now create a logical project by specifying exactly the project resources needed in term of:
62
+
Environments across multi-cloud Kubernetes Clusters.
63
+
The administrators who are maintaining those applications day-to-day
64
+
The developers working on the project
65
+
66
+
## Quota Management
67
+
Administrators should clearly define quotas for the team in order to control the resources their application can consume.
68
+
69
+
## Tagging Strategy
70
+
e introduction
71
+
72
+
73
+
74
+
75
+
76
+
## **CNO - CD**
77
+
78
+
After aligning Onboarding teams and projects easily, the next challenge is to allow organizations to choose **the fastest way to deliver applications**. **CNO CD** allows you to easily choose the best continuous deployment model that suits your needs. It’s possible to deploy applications manually or automatically. It’s also possible to choose the best advanced deployment model like Canary or Blue/Green or A/B Testing.
79
+
80
+
## Manual or Automatic Depoy
81
+
## Blue/Green
82
+
## Canary and A/B testing
83
+
Lorem ipsum dolor sit amet consectetur adipisicing elit. Eius dolores tenetur incidunt inventore. Itaque animi, accusantium fuga veritatis ipsam culpa.
84
+
85
+
## **CNO - HUB**
86
+
87
+
To **hide the Kubernetes complexity, CNO Hub** centralizes management, governance and monitoring of all your Kubernetes clusters on any cloud from a single Console.
88
+
89
+
**CNO Hub gives IT teams the tools to simplify kubernetes technology. In doing so, they can centralise the management of all their Kubernetes clusters from anywhere, from the Cloud or from their own datacenter.**
90
+
91
+
## Non-managed Clusters
92
+
## Cloud Provider managed Clusters
93
+
### **Cloud Providers**
94
+
### **Managed Clusters**
95
+
Lorem ipsum dolor sit amet consectetur adipisicing elit. Eius dolores tenetur incidunt inventore. Itaque animi, accusantium fuga veritatis ipsam culpa.
96
+
97
+
## **CNO - Secure**
98
+
To put security into the entire life cycle of project onboarding and applications development, CNO Secure gives security teams the tools and processes to integrate security without breaking innovation speed.
99
+
100
+
## IAM
101
+
CNO Secure centralizes the management of authentication and authorization of all your users across your cloud providers and Kubernetes clusters.
102
+
103
+
## Policy
104
+
CNO Secure also ensures security policies and compliance by defining and enforcing them on all your Kubernetes clusters on any cloud.
105
+
106
+
## Scan
107
+
Lorem ipsum dolor sit amet consectetur adipisicing elit. Eius dolores tenetur incidunt inventore. Itaque animi, accusantium fuga veritatis ipsam culpa.
13
108
14
109
# Architecture and System Requirements
15
110
16
111
# Installation
112
+
## **Install CNOCTL**
113
+
The CLI can be installed with a curl script, brew or by downloading the binary from the releases page. Once installed you'll get the cnoctl command.
114
+
115
+
## Install with curl:
116
+
```
117
+
$ curl -sSL https://raw.githubusercontent.com/beopencloud/cno/main/scripts/cnoctl.sh | sh
118
+
```
119
+
120
+
## Install with brew on MacOs:
121
+
```
122
+
$ brew tap beopencloud/cno
123
+
```
124
+
```
125
+
$ brew install cnoctl
126
+
```
127
+
## Install from release:
128
+
In the cnoctl release page (https://github.com/beopencloud/cno/releases) download, unarchive the version needed and move the binary to your system PATH.
Tags are elements made up of pairs (key and values) whose main purpose is to allow the identification of resources or clusters. They are defined by the user and must be relevant and specific in order to facilitate the identification of the resources to which they will be assigned.
172
+
173
+
## CREATION SYNTAX
174
+
Create a tag by giving elements of configuration
175
+
```
176
+
cnoctl adm create tag [name] [--flags]
177
+
```
178
+
The supported arguments are:
179
+
* name: The name of the tag you want to create | [REQUIRED]
180
+
The supported flags are:
181
+
* type: The type of flag text or selection | [REQUIRED]
182
+
* text type: a simple text field to assign a value to the tag
183
+
* selection type: a selection field to assign a value to the tag
184
+
* value: the value of type selection value1,value2 | [OPTIONAL]
185
+
* required : use it if our tag is required | [OPTIONAL]
186
+
187
+
## GET SYNTAX
188
+
List informations about all tag
189
+
```
190
+
cnoctl adm get tag [tag_id]
191
+
```
192
+
The supported arguments are:
193
+
* tag_id: The id of the tag from which we want to retrieve information. To specify if you want to get information about a specific tag | [OPTIONAL]
194
+
195
+
196
+
## **QUOTA Management for your Organization**
197
+
198
+
It is the different capacities allocated to a cluster that allow it to function properly. The different capacities are the cpu, the limit and the storage.
199
+
200
+
* The cpu is the value of the processor allocated to a cluster, it takes into account 2 parameters, the limit value (maximum value that can be allocated to a cluster) and the request value (the minimum value that a cluster needs to function). It is measured in Core or Mcore
201
+
* The limit is the value of the memory allocated to a cluster. Like the cpu, it takes into account a limit value and a request value. However it is measured in M,Mi,G,Gi
202
+
* The storage, that is the capacity that a cluster can have, is also measured in M,Mi,G,Gi
203
+
204
+
## CREATION SYNTAX
205
+
Create a quota by giving elements of configuration
* name: The name of the quota you want to create | [REQUIRED]
211
+
The supported flag are:
212
+
* cpu: cpu parameter limit value and request, which are separated by comma. | [REQUIRED]
213
+
* memory: memory parameter limit value and request, which are separated by comma. | [REQUIRED]
214
+
storage: storage value | [REQUIRED]
215
+
* it is not possible to put a request value, it will be deducted from the limit value
216
+
217
+
## GET
218
+
List informations about all quota
219
+
```
220
+
cnoctl adm get quota [name]
221
+
```
222
+
The supported arguments are:
223
+
* name: The name of the quota from which we want to retrieve information. To specify if you want to get information about a specific quota | [OPTIONAL]
224
+
225
+
226
+
## **Adding Cloud Providers**
227
+
228
+
Several cloud providers are supported by CNO. We use cloud providers in CNO to get Kubernetes clusters that we want to manage through CNO. Available cloud providers in CNO are AWS, Azure and Google Cloud.
229
+
Since they are different, each of them will have its own configuration.
230
+
231
+
## CREATION SYNTAX
232
+
Create a tag by giving elements of configuration
233
+
234
+
### **- AWS**
235
+
```
236
+
cnoctl adm create provider-eks [name] [--flags]
237
+
```
238
+
The supported arguments are:
239
+
* name: The name of the cloud provider you want to create | [REQUIRED]
240
+
The supported flags are:
241
+
* default-region: The region of the provider | [REQUIRED]
242
+
* access-key: Access key for Aws cloud provider | [REQUIRED]
243
+
* secret-key: Secret key for Aws cloud provider | [REQUIRED]
244
+
* session-token: Session Token for Aws cloud provider | [REQUIRED]
245
+
246
+
### **- AZURE**
247
+
```
248
+
cnoctl adm create provider-aks [name] [--flags]
249
+
```
250
+
The supported arguments are:
251
+
* name: The name of the cloud provider you want to create | [REQUIRED]
252
+
The supported flags are:
253
+
* client-id: The client-id for aks provider | [REQUIRED]
254
+
* client-secret: The client secret for aks provider | [REQUIRED]
255
+
* subscription-id: The subscription id for aks provider | [REQUIRED]
256
+
* tenant-id: The tenant id of the aks provider | [REQUIRED]
257
+
### **- GCP**
258
+
```
259
+
cnoctl adm create provider-gke [name] [--flags]
260
+
```
261
+
The supported arguments are:
262
+
* name: The name of the cloud provider you want to create | [REQUIRED]
263
+
The supported flags are:
264
+
* Json-file: The json file that contains the configuration of the gke provider | [REQUIRED]
265
+
266
+
267
+
## GET SYNTAX
268
+
List informations about all cloud provider
269
+
```
270
+
cnoctl adm get provider [name]
271
+
```
272
+
The supported arguments are:
273
+
* name: The name of the cloud provider from which we want to retrieve information. To specify if you want to get information about a specific provider | [OPTIONAL]
274
+
275
+
276
+
## **LDAP Configuration**
277
+
## Configure Ldap Account
278
+
Ldap Account consists of creating an Ldap Server to store and use users, group.
279
+
280
+
Creating ldap account by giving the following command
281
+
```
282
+
cnoctl adm create ldap [--flags ]
283
+
```
284
+
The supported flags are:
285
+
* url: The url of your ldap account | [REQUIRED]
286
+
* port: The port of the ldap account (389 for ldap, 634 for ldaps) | [REQUIRED]
287
+
* cn: The common name of the ldap server | [REQUIRED]
288
+
* basedn: The base domain name | [REQUIRED]
289
+
* admin-password: define the ldap admin password | [REQUIRED]
290
+
291
+
292
+
## Get LDAP Account
293
+
List informations about your Ldap Account
294
+
```
295
+
cnoctl adm get ldap
296
+
```
297
+
298
+
## **Configure Messaging**
299
+
Messaging Account consists of creating an SMTP server to send emails or notifications to CNO users.
300
+
301
+
Create a messaging account by giving elements of configuration
302
+
```
303
+
cnoctl adm create smtp [--flags]
304
+
```
305
+
The supported flags are:
306
+
* email: The sender email of your organization | [REQUIRED]
307
+
* smtp-password: The sender email account password | [REQUIRED]
308
+
* smtp-server: The name of the most common email providers' servers | [REQUIRED]
309
+
* smtp-port: The port of the email provider's servers | [REQUIRED]
310
+
311
+
## GET SYNTAX
312
+
List informations about Your Messaging Account
313
+
```
314
+
cnoctl adm get smtp
315
+
```
316
+
317
+
## TEST SYNTAX
318
+
Do a test to make sure that the smtp server configuration is correct
0 commit comments