Difference between revisions of "Procedure Infrastructure Deployment"
| Line 36: | Line 36: | ||
A shiny app can be deployed in the D4Science Infrastructure in different ways, using the ''ShinyProxy App'' tracker in the [https://support.d4science.org/ Redmine system]: | A shiny app can be deployed in the D4Science Infrastructure in different ways, using the ''ShinyProxy App'' tracker in the [https://support.d4science.org/ Redmine system]: | ||
| − | * It can be a public app already available in [https://hub.docker.com Docker Hub] or any other public container registry. In this case, the image name and the ''run command'' are the only requirements. | + | * It can be a public app already available in [https://hub.docker.com Docker Hub] or any other public container registry. In this case, the image name and the ''run command'' are the only requirements. Docker Hub can automatically build and push images from a public repository, as described in its [https://docs.docker.com/docker-hub/builds/ builds] documentation. The general Docker Hub documentation is [https://docs.docker.com/docker-hub/ here] |
* A build of a public image can be requested. For that activity, a public repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into [https://hub.docker.com Docker Hub]. | * A build of a public image can be requested. For that activity, a public repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into [https://hub.docker.com Docker Hub]. | ||
* A build of a private image can be requested. For that activity, a repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into the D4Science's private registry. | * A build of a private image can be requested. For that activity, a repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into the D4Science's private registry. | ||
| Line 47: | Line 47: | ||
A container can be deployed in the D4Science Infrastructure in different ways, using the ''Docker Image'' tracker in the [https://support.d4science.org/ Redmine system]: | A container can be deployed in the D4Science Infrastructure in different ways, using the ''Docker Image'' tracker in the [https://support.d4science.org/ Redmine system]: | ||
| − | * It can be a public container already available in [https://hub.docker.com Docker Hub] or any other public container registry. | + | * It can be a public container already available in [https://hub.docker.com Docker Hub] or any other public container registry. Docker Hub can automatically build and push images from a public repository, as described in its [https://docs.docker.com/docker-hub/builds/ builds] documentation. The general Docker Hub documentation is [https://docs.docker.com/docker-hub/ here]. |
* A build of a public image can be requested. For that activity, a public repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into [https://hub.docker.com Docker Hub] and then deployed into the Swarm cluster. | * A build of a public image can be requested. For that activity, a public repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into [https://hub.docker.com Docker Hub] and then deployed into the Swarm cluster. | ||
* A build of a private image can be requested. For that activity, a repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into the D4Science's private registry and then deployed int the Swarm cluster. | * A build of a private image can be requested. For that activity, a repository must be accessible from our [https://jenkins.d4science.org Jenkins] instance so that the process can be automated. The result container image will be uploaded into the D4Science's private registry and then deployed int the Swarm cluster. | ||
Revision as of 12:51, 27 February 2020
gCube Resources
The gCube nodes of the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Infrastructure can be deployed in 32 and 64 bits machines and supports several Linux distributions. It has been tested on CERN Scientific Linux, RedHat Enterprise, Ubuntu, and Fedora.
A gCube node of the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Infrastructure is composed by two main constituents:
- A base gHN-distribution or SmartGears distribution Managed locally by Site Managers;
- gCube services running on the gHN or on the Smartgears container. Managed remotely by VO Admins and the VRE Managers.
Installation
- gHN - The gHN distribution is available from the gCube website. The Administrator Guide provides detailed information about the gHN installation process.
- SmartGears - The SmartGears distribution is available from the gCube website. The Smargears installation guide provides information about the Smartgears installation process
- gCube Service - gCube services are installed when new VOs/VREs are deployed. Check the VO Creation and VRE Creation procedures.
Upgrade
- gHN and SmartGears - The upgrade of gHNs is based on upgrade plans published in the Resources Upgrade page.
- gCube - The upgrade of gCube services is based on upgrade plans published in the Resources Upgrade page.
In order to coordinate Installation and Upgrade activities the Infrastructure Managers use the Redmine system. For each activity the Infrastructure Managers should open a "D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Infrastructure" RedMine ticket describing the activity to perform and assign it to a Site Managers with a Due Date.
Site Managers responsible of the tasks when closing the ticket are supposed to fill the field Intervention Time with the time spent performing the task.
Tickets associated with installation and upgrades are also reported in the Resources Upgrade page. More information is available on the Infrastructure upgrade wiki
Shiny(Proxy) apps
- Shiny apps can be deployed in the infrastructure. Two instances of shinyproxy, one under public access and one behind authentication, are available.
- Shiny apps are docker containers that can be built following the shinyproxy guidelines at [1].
Build and Installation
A shiny app can be deployed in the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Infrastructure in different ways, using the ShinyProxy App tracker in the Redmine system:
- It can be a public app already available in Docker Hub or any other public container registry. In this case, the image name and the run command are the only requirements. Docker Hub can automatically build and push images from a public repository, as described in its builds documentation. The general Docker Hub documentation is here
- A build of a public image can be requested. For that activity, a public repository must be accessible from our Jenkins instance so that the process can be automated. The result container image will be uploaded into Docker Hub.
- A build of a private image can be requested. For that activity, a repository must be accessible from our Jenkins instance so that the process can be automated. The result container image will be uploaded into the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative.'s private registry.
Docker containers
A Docker Swarm cluster is available to deploy and run Docker containers. Only Docker containers are supported at this time.
Build and Installation
A container can be deployed in the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Infrastructure in different ways, using the Docker Image tracker in the Redmine system:
- It can be a public container already available in Docker Hub or any other public container registry. Docker Hub can automatically build and push images from a public repository, as described in its builds documentation. The general Docker Hub documentation is here.
- A build of a public image can be requested. For that activity, a public repository must be accessible from our Jenkins instance so that the process can be automated. The result container image will be uploaded into Docker Hub and then deployed into the Swarm cluster.
- A build of a private image can be requested. For that activity, a repository must be accessible from our Jenkins instance so that the process can be automated. The result container image will be uploaded into the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative.'s private registry and then deployed int the Swarm cluster.
The image name, the replica factor and, where appropriate, the external configuration and storage requirements must be specified in the request.
Hadoop and Runtime Resources
Hadoop and Runtime Resources installation and upgrades due to the diverse nature of Service and installation type does not follow a predefined installation or upgrade procedure, but as for the gCube Resources each action is associated with a Redmine ticket where Site Managers have to report the Intervention Time spent.
