Skip to content
Snippets Groups Projects
Commit cea8d3fa authored by Vojdan Kjorveziroski's avatar Vojdan Kjorveziroski
Browse files

Changes after proofreading

parent 8d58416d
No related branches found
No related tags found
1 merge request!23Resolve "Update the all-in-one VM guide"
......@@ -2,6 +2,6 @@
Network management is an essential part of any production network, no matter its size. However, organizations often face staff shortages or lack the required resources to properly monitor their network. nmaas (Network Management as a Service) is a GÉANT production service that allows effortless deployment of many open-source network monitoring tools on demand, with minimal initial configuration by the end users. Based on the Kubernetes container orchestrator, and deployable on private infrastructure as well, a dedicated nmaas instance can be used as a central point for monitoring many distributed networks, by utilizing VPN tunnels. New applications can be added to the nmaas catalogue at any time using Helm charts, an industry standard package manager for Kubernetes. nmaas hides the operational complexity from end users who access the service through a web application from where they can manage and configure their existing application instances or deploy new ones.
If you want to follow this tutorial, please make sure that you have either downloaded the [pre-prepared VM](../all-in-one-vm-image.md) or have followed the necessary steps for deploying a local Kubernetes clusters and installing an nmaas test instance. After completing these prerequisites, this tutorial continues with [setting up a demo network environment](./p3_demo-network-environment.md), where virtualized demo networking devices are used that can later act as monitoring targets for the applications deployed by nmaas. The process of deploying such monitoring applications from the list of supported applications in the nmaas catalog is described in the part on [monitoring the demo network environment](./p4_monitoring-demo-network-environment.md). The tutorial is concluded with [instructions on adding a custom application](./p5_adding_custom_app.md), allowing advanced users to add their own applications to the nmaas catalog, thus making it available to all potential users of their nmaas instance.
If you want to follow this tutorial, please make sure that you have either downloaded the [pre-prepared VM](../all-in-one-vm-image.md) or have followed the necessary steps for deploying a local Kubernetes cluster and installing an nmaas test instance. After completing these prerequisites, this tutorial continues with [setting up a demo network environment](./p3_demo-network-environment.md), where virtualized demo networking devices are used that can later act as monitoring targets for the applications deployed by nmaas. The process of deploying such monitoring applications from the list of supported applications in the nmaas catalog is described in the part on [monitoring the demo network environment](./p4_monitoring-demo-network-environment.md). The tutorial is concluded with [instructions on adding a custom application](./p5_adding_custom_app.md), allowing advanced users to add their own applications to the nmaas catalog, thus making it available to all potential users of their nmaas instance.
For users who choose to download the already prepared virtual machine and avoid the whole setup process, the [Appendix](./appendix.md) gives an overview of all the credentials that have been used.
\ No newline at end of file
......@@ -6,7 +6,7 @@
!!! note "Clarification"
This guides assumes that a local deployment of nmaas already exists and that either you are working in the provided nmaas test VM or you have followed the [instructions to deploy nmaas from scratch locally](../deploying-local-kubernetes-cluster.md).
This guide assumes that a local deployment of nmaas already exists and that either you are working in the provided nmaas test VM or you have followed the [instructions to deploy nmaas from scratch locally](../deploying-local-kubernetes-cluster.md).
If there are existing network elements ready to be monitored by nmaas applications, then this part can be completely skipped.
......
......@@ -4,11 +4,11 @@
The virtual lab manager role is a global nmaas role that allows access to the bulk domain deployment and bulk application deployment features, among other things. To become a virtual lab manager on the manager vLAB nmaas instance, please contact the nmaas team using the [contact form](https://vlab.dev.nmaas.eu/about?type=VLAB_REQUEST). If you have access to a self-hosted nmaas instance, the global nmaas administrator can promote registered users to virtual lab managers.
Bulk domain deployments allow a virtual lab manager to registered multiple virtual lab participants at once, using a simple CSV import process. During the user import, the necessary domain groups are created as well. A "domain groups" is an nmaas feature that allows nmaas administrators to restrict which applications are available for deployment to given domains. This feature is useful for scenarios where a group of domains should have access to a restricted set of applications, instead of the whole catalog.
Bulk domain deployments allow a virtual lab manager to register multiple virtual lab participants at once, using a simple CSV import process. During the user import, the necessary domain groups are created as well. A "domain groups" is an nmaas feature that allows nmaas administrators to restrict which applications are available for deployment to given domains. This feature is useful for scenarios where a group of domains should have access to a restricted set of applications, instead of the whole catalog.
An example scenario for domain groups and one for which they were originally developed is virtual lab. When organizing virtual labs on nmaas, it is expected that many different users might need access to a different set of applications, but not to the whole catalog at once. This is the case when a university uses nmaas for conducting virtual labs for multiple courses. Students enrolled in course A might need access to applications 1, 2, and 3, while students in course B might need access to applications 4, 5, and 6. Assuming that the complete nmaas catalog also includes applications aimed at the teaching staff which might require additional compute resources or present security risks when deployed by students, such applications should not be deployable in the students' domains.
A prerequisite for performing a bulk domain deployment is to have the necessary information for each lab participant expected to take part in the virtual lab. This includes the domain name for their domain, their username used for logging in to the system, the name of the domain group to which the domain should be part of and the email address of the user. Note that the bulk domain deployment process is idempotent, meaning that it can be repeated multiple times with the same data, without introducing any undesired changes. If a given lab participant already has an account and a domain in the system, their domain will simply be assigned to the specified domain groups, in addition to the ones to which it is already part of. Similarly for the domain groups, they are created only if no domain group with the same ID exists in the system, otherwise the creation process is skipped and only the new/existing domains are associated with it. A common approach for acquiring the necessary virtual lab participant data before continuing with the registration is to perform an export of the course participants from the LMS, if one is in use.
A prerequisite for performing a bulk domain deployment is to have the necessary information for each lab participant expected to take part in the virtual lab. This includes the domain name for their domain, their username used for logging in to the system, the name of the domain group that the domain should be part of and the email address of the user. Note that the bulk domain deployment process is idempotent, meaning that it can be repeated multiple times with the same data, without introducing any undesired changes. If a given lab participant already has an account and a domain in the system, their domain will simply be assigned to the specified domain groups, in addition to those it is already part of. Similarly for the domain groups, they are created only if no domain group with the same ID exists in the system, otherwise the creation process is skipped and only the new/existing domains are associated with it. A common approach for acquiring the necessary virtual lab participant data before continuing with the registration is to perform an export of the course participants from the LMS, if one is in use.
The steps to perform the bulk domain deployments are explained in detail below.
......@@ -29,14 +29,14 @@ No matter the chosen approach, the bulk domain deployment wizard shows the expec
The required fields are:
- `domain` - the name of the domain to which the user should be part of. If it exists, the user is simply added to it as a member. If it does not exist, it is created, and then the user is made part of it.
- `username` - the username for the user. If it exists, the user is added to the listed domain. If it does not exist, it is created and then added to the domain.
- `domain` - the name of the domain that the user should be part of. If it exists, the user is simply added to it as a member. If it does not exist, it is created, and then the user is made part of it.
- `username` - the username for the user. If it exists, the user is added to the given domain. If it does not exist, it is created and then added to the domain.
- `networks` - should be left blank, reserved for future use.
- `domainGroups` - domain groups to which the domain needs to be part of. If a domain group already exists, the given domain is added to it. If the domain group does not exist, it is first created, and then the domains are joined to it.
- `domainGroups` - domain groups that the domain needs to be part of. If a domain group already exists, the given domain is added to it. If the domain group does not exist, it is first created, and then the domains are joined to it.
- `email` - the email of the user. If email notifications are enabled at the nmaas instance level, a welcome email will be sent to the user.
- `ssoEnabled` - whether the user can login using the `Federated login` option or not. This is useful if the first import of users is done from an LMS export, but subsequent logins need to be done via SSO. This allows the user accounts to be fully set up and joined to the respective domain groups before the virtual lab participants are allowed to login to the system for the first time.
After providing the content and clicking either the `Upload file` button or the `Upload csv content` button, depending on whether the CSV file was uploaded or its content were pasted in the text area, the bulk domain deployment process will be initiated. After a couple of moments, an overview page will be shown, explaining the action that was taken for each user and domain.
After providing the content and clicking either the `Upload file` button or the `Upload csv content` button, depending on whether the CSV file was uploaded or its content was pasted in the text area, the bulk domain deployment process will be initiated. After a couple of moments, an overview page will be shown, explaining the action that was taken for each user and domain.
![Bulk Domain Deployment Overview](img/03-bulk-domain-deployment-overview.png)
......
......@@ -5,7 +5,7 @@
If a virtual lab participant logs in to their newly created account before the virtual lab manager has had a chance to customize the list of whitelisted applications, they will simply see a blank catalog. No applications will be available for deployment, thus preventing any unexpected and unauthorized use of the available computing resources. Of course, if the participant has already been a member of a different domain group that contains whitelisted applications, these will still be available for deployment.
It is recommended that as soon as new domain groups are created, either manually or automatically using the bulk domain deployment feature, they are customized so that applications are whitelisted. Virtual lab managers can do this by using the cog wheel button in the top navigation menu and choosing the domain groups option. Once the details for a given domain group are opened, applications can be whitelisted using the `Application properties` section.
It is recommended that as soon as new domain groups are created, either manually or automatically using the bulk domain deployment feature, they are customized so that applications are whitelisted. Virtual lab managers can do this by using the cog wheel symbol in the top navigation menu and choosing the domain groups option. Once the details for a given domain group are opened, applications can be whitelisted using the `Application properties` section.
![Whitelisting Applications in a Domain Group](img/04-domain-group-app-whitelist.png)
......
......@@ -9,7 +9,7 @@ The initial step that needs to be performed is "subscribing" to the application
![PostgreSQL Deployment - Step 01](img/06-postgresql-step1.png)
The next user action that is required is to fill out the configuration parameters for the given application. Each application can specify configuration parameters that need to be customizable by the end-users during deployment. In the case of the PostgreSQL application these are:
The next user action that is required is to fill out the configuration parameters for the given application. Each application can specify configuration parameters that need to be customized by the end-users during deployment. In the case of the PostgreSQL application these are:
- Root password
- Database user
......@@ -32,7 +32,7 @@ As Adminer is a web based application, it does expose a web interface that can b
![Adminer Deployment - Accessing the Application](img/10-adminer-deployment-app-access.png)
In the managed nmaas instances, to remotely access the deployed applications the users need a client-access VPN connection. If you are using a self-hosted nmaas instance deployed in the premise or in a commercial cloud, the access strategy might differ. In the text that follows we will focus on the required steps to access the deployed instances when using the managed nmaas service.
In the managed nmaas instances, to remotely access the deployed applications the users need a client-access VPN connection. If you are using a self-hosted nmaas instance deployed on premise or in a commercial cloud, the access strategy might differ. In the text that follows we will focus on the required steps to access the deployed instances when using the managed nmaas service.
The [vlab.dev.nmaas.eu](https://vlab.dev.nmaas.eu) instance requires the use of [eduVPN](https://www.eduvpn.org/) to access the applications remotely. eduVPN is an open-source VPN server and client developed within the GÉANT project. It uses the well-known and robust OpenVPN and Wireguard protocols behind the scenes. The major advantage that eduVPN provides is that users can login using SSO and generate new VPN profiles for all their devices, without a need for administrator intervention.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment