Skip to main content
Version: 10.9.x

Create a Company

A company is the resource which has the governance of all the projects inside it. It is possible to connect the infrastructure on which projects can be based, analyze the configuration of all projects inside the company and manage users and permissions inside the company.

info

The company creation in Mia-Platform on-premise Console is linked to the license. If you want to create a new company, contact your Mia-Platform referent.

caution

To create a company in the Mia-Platform SaaS Console, you must open a Service Request and the company will be created for you.

Requirements​

To create a company, you must have access to the Console Backoffice (granted with the group console_cms) and permission console.root.company.create.

Create a company​

It's possible to create a company from API. The API is visible inside the Console API Portal, under the Companies tag.

The API is a POST to /api/backend/companies, and it is possible to set the name and description of the company to add. In addition, when you create the company you will be added as Company Owner.

caution

This API could change in future in a not backwards compatible way

In the company, you could configure:

  • git providers which can be used by the project inside the company
  • clusters which can be used by the projects inside the company
  • default configurations to be used during the creation of new projects

Let's now configure the company to prepare itself to the creation of a new project.

Add the first Company User​

info

If you used the API to create the company, you can skip this section.

If your company has been created by CMS, you have to add the first user to it, who may be yourself or another user in the Platform. Regardless, head over to the CMS page and choose the Bindings menu item (only a restricted set of users have access to this section, ask your Console Administrator if you need access to it).

In the Bindings section, click the Create new button and fill in the form, type a custom Binding ID, select the proper Role (since it is the first user, usually it should be Company Owner) and make sure to select the correct user as Subject. Finally, you'll have to assign the correct resource by filling it with an object as follows:

{
  "resourceType": "company",
  "resourceId": "THE ID YOU PROVIDED UPON CREATION AS tenantId"
}
danger

The Binding ID must be unique in the whole collection!
As a general recommendation we suggest {tenantId}-{desiredRole}, but in some cases something more complex may be needed.

Create a new Git Provider​

To create a new provider, you can follow the providers guide.

Connect a cluster​

To connect a cluster, you can follow the cluster guide.

Default configuration for a new project​

This configuration can be done using the Console Backoffice.

The fields necessary for this collection are:

  • defaultTemplateId: the default template to be used in the project creation. This information can be changed in the project creation wizard steps;

  • cmsImageName: CMS Docker image to interpolate in template archive. It should also contain the CMS tag to use (if cms-site service is disabled in the project creation, it will not be used);

  • repository (required): object which specifies the information about the repository where the projects of this company have to be created. The object must have the following properties:

    • providerId (required): providerId existing into the provider's CRUD. It is used to get information about the provider to use. This ID is important because it affects many requests used by the developer Console;
    • basePath: base path where the project will be created. The user needs to have permission for creating projects on this path;
    • visibility: visibility of the project.
info

Here some tips on how to correctly configure the basePath property, grouped by Git provider:

The basePath is the basePath of the group where to create the project.

If the group does not exist, it will be created only if the user has the needed permission to create the group in its parent.

E.g.

  • /groupA/groupB -> if groupB does not exist AND user have permission to create groups in groupA, then groupB will be created;
  • /groupA/groupB -> if groupB does not exist AND user have no permission to create groups in A, then groupB will NOT be created;
  • /groupA/groupB -> if groupB does not exist AND groupA does not exist, then it will NOT be created any group.

  • environments (required): an array of objects containing the definitions of the environments for the company. The content of this arrays will be interpolated to replace %projectId% by inserting the projectId field in the project creation. Each object should contain, for example:

      {
        "label": "Development",
        "envId": "development",
        "envPrefix": "development",
        "hosts": [
          {
            "host": "%projectId%.test.mia-platform.eu",
            "scheme": "https"
          },
          {
            "host": "cms.%projectId%.test.mia-platform.eu",
            "isBackoffice": true
          }
        ],
        "cluster": {
          "clusterId": "human-readable-id-of-the-cluster",
          "namespace": "%projectId%-development",
          "kubeContextVariables": {
            "KUBE_URL": "KUBE_DEV_URL",
            "KUBE_TOKEN": "KUBE_DEV_TOKEN"
          }
        }
      }
    caution

    The term tenantId is the new word that refers to the old companyId.

    danger

    Do not set in the cluster.kubeContextVariables object the plain values to access the cluster. Write the variable key name for the specified environment (as shown in the example). The values saved here are not encrypted!

  • pipelines (required): the CI/CD pipelines used by the company, for example:

    {
      "type": "gitlab-ci"
    }

  • environmentVariables: an object which describes the configuration to enable the Variables section in the Project Settings area of the Console. The only supported type is gitlab.

    There are three ways to configure a project:

    1. empty: it is not set as default in the project creation, but should be configured manually after the process;

    2. only type configuration, for example:

      {
        "type": "gitlab"
      }

      The project reads the variables from the first parent group of the Configurations project in GitLab.

      As an example, with a GitLab project to be saved in /clients/mia-platform/configurations, the environment variables are written in the clients/mia-platform group;

    3. complete configuration, for example:

      {
        "type": "gitlab",
        "baseUrl": "https://my-gitlab-host",
        "storage": {
          "type": "projects",
          "path": "clients/mia-platform/configurations"
        }
      }

      This configuration is saved only within the company, and should be retrieved at runtime in project fetching from company info. So if your company has all environment variables of the projects set in the parent group, this setting might be changed for all projects at the same time.

  • logicalScopeLayers: an array of objects identifying the set of logical layers available in the current company. Each object is shaped as follows:

    • name: identifies the name of the logical layer;
    • order: identifies the numerical order of the layer, in order to display it according to the sorting defined by the user. When a project is merged with its company information, the logicalScopeLayers will be created in the project model according to its layerId value. Please refer to the section [How to create a project on Console] for further details.

  • availableNamespaces: namespaces internally accessible from your project, using the cross-projects endpoint. It is useful when your company is made up of several projects that communicate with each other. The content of this array will be interpolated to replace %projectId% with the projectId field in the project creation;

  • dockerImageNameSuggestion: object which defines the Docker image name suggestion that will be passed to every project created in your company. This suggestion will appear in the Docker Image Name field when you create a microservice. The object should have the following properties:

    • type (required): string which defines the type of suggestion. Currently, there exist three types:

      • PROJECT_ID (default): the suggestion for the Docker image name will be in the following format: <project-id>/<your-service-name>. This is the default behavior, even without setting this property the suggestion will follow this format. You must not set the prefix property if you have chosen this type;
      • REPOSITORY: the suggestion for the Docker image name will be in the following format: <your-group-name>/<your-repo-name>. You must not set the prefix property if you have chosen this type;
      • CONSTANT_PREFIX: the suggestion for the Docker image name will be in the following format: <prefix-value>/<your-service-name>. The prefix property is required for this type and will replace prefix-value.

    • prefix: string that defines the prefix that will appear in the suggestion for the Docker image name. This property must be defined only when type property value is set to CONSTANT_PREFIX.

info

<your-service-name>, <your-group-name>, <your-repo-name>, are field values that you will decide during the creation of a microservice. Some of these values must be defined in order to receive a suggestion for the Docker image name (depending on the suggestion type).

  • imagePullSecretNames: a list of imagePullSecret names that will be inherited in the project during project creation and then used in deployment and cronjob files for pulling docker images

  • enabledSecurityFeatures: a set of features to enforce the security of the project. For further details, take a look at the last section of this page.