The instructions below can be downloaded following thislink.
vf-OS intends to be the reference system/platform for providing common services for manufacturing industry. Like a regular OS, vf-OS has core functionalities but is focused on a manufacturing environment. An analogy between some components of a regular Software OS and the vf-OS Manufacturing OS is presented in Figure 1 (as introduced in the vf-OS D1.1 Vision Consensus).
Devices Drivers, APIs Connectors, Security, and Data Access
File and Data handling
Data Infrastructure Middleware, Data Storage, Data Harmonisation, Data Analytics
SDK, Application Development portal, System Monitor
System Dashboard, Front End Environment, Studio, Developer Engagement Hub
ERPs, CRMs, MES
Equipment real-time data collection, Monitoring, and alerting, …
Developer Environment, App Store, Internet, and Service Provision
vf-OS Engagement hub, vf-OS Studio, Manufacturing Applications Store (vf-Store)
Figure 1: Analogy between Software OS and Manufacturing OS
Who Should Read this Page?
Since deploying the vf-OS Environment is not an easy task, this document should be read by an IT System Administrator capable of understanding the jargon used in this document. This person should be familiar with terms like Docker, NPM, Git and similar technologies. In addition, the IT System Administrator must be also familiar with administering Linux environments and understanding Service Oriented Architectures.
Positioning in overall vf-OS Architecture
Figure 2 is an overview of the high-level architecture of vf-OS providing a formal split of functional components, as already described in D2.1.
Figure 2: vf-OS High-Level Architecture
Virtual Factory System Kernel is the core of the operating system. It is responsible for providing key system wide vf-OS resources and providing a set of specific services, which are open and accessible. It is a specific set of libraries and infrastructure for vApps to be built upon and interact with each other; it is composed of a Framework, Generic Enablers and Manufacturing Enablers.
The vf-OS kernel (vf-SK) represents the elements for implementing services supported by enablers. vf-SK also implements the paradigm of being open and accessible as well as supporting interaction with manufacturing applications (vApps) and their devices if applicable. The vf-SK is a set of libraries and infrastructure to enable vf-OS Assets to be built upon by utilising functionalities provided by the different enablers. vf-SK is intended to be installed on-premise but is not classified as an independent separate vf-OS component. In this sense, the aim of vf-SK is to provide functionalities for processing and mediating the access to open vf-OS resources.
vf-SK is particularly focused on providing integration and accessibility functionalities across Generic Enablers, Manufacturing Enablers, vf-OS Enablers (and Process enablers). This is achieved through the definition and development of a framework, which can generically fit existing FIWARE and Manufacturing enablers and vf-OS enablers. The framework, which is called Enablers Framework (EF) in the vf-OS architecture, provides functionalities for uniformly accessing the functionalities exposed by different enablers with diverse interfaces. These functionalities are a set of services, such as complex event processing, context management, stream processing, network, and information control, etc. Additionally, EF provides methodologies and policies that facilitate the development and distribution of new enablers in the scope of T3.4. The methodologies are adapted from the guidelines provided by FIWARE, thus paving the path for vf-OS Enablers to be part of FIWARE ecosystem in future.
Virtual Factory Input/Output Interface is a set of modules that virtualise factory's real assets and connect them to their images in vf-OS. vf-IO implements Plug-and-Play mechanisms and device drivers for seamless/open access and smart virtualisation of the factory resources; it is composed by devices drivers, API connectors, security, and data access. Thus, the vf-IO is composed of the modules that enable connectivity to assets like legacy ERPs or CRMs, CPSs, smart objects or wireless sensor networks. All these components are referred to as IO Components.
Fundamentally, IO Components connect new assets (devices, services, applications, etc.) to the vf-OS Platform and the IO Toolkit provides functionalities to guarantee the interoperability of such assets. Thus, the IO Toolkit ensures that IO Components are compatible with vf-OS and can be used in vApps through known interfaces.
As shown in Figure 2, at runtime, the IO Toolkit implements core functionalities to integrate components into the vf-OS Platform and enable the exchange of data with other components (Security, Registration, middleware endpoints, etc.).
At design time, the IO Toolkit provides additional development resources to Manufacturing and Logistics Solutions Providers wishing to develop new IO Components to connect new manufacturing resources and services to vf-OS.
For both scenarios, it is important to understand the relationship between the OAK Toolkit and the IO Toolkit. The OAK Toolkit is for the development of vApps by Software Developers, whereas the IO Toolkit is for the development of new IO Components. In the context of connecting vf-OS to manufacturing assets:
The OAK SDK provides programming interfaces to access data and services from the IO Components available in the vf-OS Platform, so that they can be used within vApps
The IO Toolkit provides development resources to facilitate the development of new interoperability mechanisms with devices and on-premise software applications and services by third parties. The IO Toolkit development resources consist of:
The IO Toolkit SDK: Implementation of the IO Toolkit functionalities in each technology. The IO Toolkit functionalities enable interaction with other vf-OS components
Documentation: Document describing the functionalities of the IO Toolkit and containing examples, best practices, and guidelines to facilitate the development of new components.
Virtual Factory Middleware is a set of modules for integrating data from arbitrary sources, ie, vf-IO modules. The vf-MW provides data infrastructure, data storage, data harmonisation, and data analytics features. The use of Cloud-based data storage avoids vendor lock-in issues and minimises the risk of system failures. Consideration will also be given if Cloud-based data storage is not available anymore. Accessibility of data will be facilitated through connectors and wrappers.
The virtual factory Middleware (vf-MW) is one of the components of the Open Operating System for Virtual Factories as referenced in D2.1: Global Architecture.
Figure 2 is an overview of the high-level architecture of vf-OS providing a formal split of functional components, as already described in D2.1. As vf-MW is particularly focused on providing data infrastructure including interoperability connectors, storage, transformation services, and analytics functionality, this is achieved through the development of six key components, according to the Figure 2.
It is important to define the purpose of the vf-MW components to set up the scene where these components are being developed:
OAK Toolkit: Data Mapping: To define the Manufacturing Maps that will allow the transformation and integration of data
Middleware: Messaging: To provide a unified infrastructure for data (message) transport between vf-OS components
Middleware: Publish/Subscribe: To provide a communication infrastructure based on a publish/subscribe pattern by creating topics or by dynamically inspecting message content to enable listening applications to subscribe to specific messages
Data Management:Data Storage: To implement a scalable data storage system, capable of handling real-time sensor data and events, based on an underlying infrastructure that transparently absorbs very large amounts of data, as well as other types of non-real-time heterogeneous data
Data Management:Data Transformation: To integrate data from concrete existing software systems by executing the Manufacturing Maps created in the Data Mapping component, ie transforming data from its source format to its destination format
Data Management:Data Analytics: To provide business analytic functionalities to derive events from stream and historic process data within the manufacturing domain.
Open Applications Development Kit is composed of an SDK to develop applications, a System Dashboard, the OAK Frontend Environment, the OAK Development Studio and a Developer Engagement Hub to engage developers. The SDK implements all the necessary APIs needed to develop vApps. The OAK System Dashboard represents the core software services for allowing system monitoring and configuration; the OAK Frontend Environment provides a framework that facilitates a general 'look, feel, and composition' to vApps and will assist rapid development, by providing a compilation of UI elements including business logic via the OAK Studio; the vf-OS Development Studio is a desktop development environment that facilitates software developers to compose their applications for running within vf-OS. Additionally, the Developer Engagement Hub is a collaboration platform for developers to support each other.
To set the scene as to where these components are being developed, it is important to define the purpose of the vf-OAK components:
OAK Toolkit: SDK: To define the APIs and access points that will allow every vf-OS asset and the final developers to have access to the other vf-OS assets (vAssets)
OAK Toolkit: Frontend Environment: To provide tools and assets that permit and promote the establishment of a Frontend Interface for the vApps
OAK Toolkit: Studio: To host a developing environment that eases the procedures required for the development such as code building and editing and most actions that relate to the development
Engagement: Hub: To create a platform that fosters the engagement of other vf-OS developers but also of the development community as a whole
Control: System Dashboard: To provide elements that allow the monitoring and control of the developed vApps.
Virtual Factory Platform is a holistic service platform, which is the foundation for all services and end user applications that vf-OS will provide. vf-P encapsulates and acts as the interface and runtime environment between the components, connectors, OAK functions, marketplace, the service framework (supporting the running of intrinsic services and vApps) and the end user applications/developers. The vf-P can run locally and in Cloud environments.
Virtual Factory Manufacturing Application Store offers fundamental services of a modern e-Commerce platform for consumer and developers. First, vf-Store enables software developers to offer assets (demanded or initiative), and second, users can search for, obtain and rate existing vApps. Furthermore, the vf-Store acts as a mediator between developers and users. Therefore, the vf-Store is the central point for developers to get in contact with users. In addition to view/set ratings, review, and provide technical information about the asset's behaviour, the vf-Store supports users to get in contact with developers to offer ideas for new assets.
It is important to define the purpose of the vf-Platform to set up the scenery where this environment is being developed:
vf-OS Platform: Execution Environment: The primary role of the platform is to provide a uniform, controlled environment for the execution of vApps and the underlying micro-services
vf-OS Platform: Portal: The platform's portal provides a single point of access for users, customers, and developers, to access the various resources, applications, etc
Marketplace Services: Marketplace: Distribution of applications is supported by the vf-Store marketplace, through which developers can sell their applications and services to users
I/O Toolkit: External Services Provisioning: To support integration with external (data) services, WP7 provides an External Services Provisioning framework. The primary purpose of this framework is to integrate external services into the communication and security realm of the vf-OS system.
vf-OS Smart Manufacturing Applications: vApps
Virtual Factory Manufacturing Smart Application is a vf-OS application, whose aim is to enable and optimise communication and collaboration among supply networks across all manufacturing sectors and in all the stages of manufacturing and logistic processes: demand forecast, planning, supply, manufacturing, distribution, storage, replacement, and recycling.
Like in the mobile environment, for downloading and executing any application valid for the manufacturing domain, there is a need to have installed within the premises of the factory (or have accessible) an instance of the vf-OS Platform, since it is the main component for executing the vf-OS environment.
As such, the first action to be carried out in every manufacturing environment is to download and deploy the vf-OS Platform within the factory premises.
Platform Environment Description
The vf-OS Platform is formed by microservices running in docker containers. Each microservice has its own purpose, which is described below.
Figure 3: Overview of the Platform Services
The platform is running inside a Docker host installation, managed by a Docker container having Docker-Compose. This central container is called the Execution-control service. This service is normally not directly accessed, but called by the execution-manager, described below.
This microservice is responsible for managing the ecosystem of the vf-OS Platform. It interacts with the execution-control service to execute docker commands, configure settings and get information from it. Running vAssets can interact with execution manager through REST API's to perform certain asset maintenance tasks, like start, stop, and removal of assets.
The reverse-proxy is a microservice that runs Træfik. Træfik is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy.
It is through this microservice that vAssets can exchange/request information between each other and/or have access to other resources outside of the vf-OS Platform. For any communication coming from outside of the vf-OS Platform must pass first through this microservice. As such, this microservice forms the SCC module (Security Contact Center), providing the security checks for all inter-asset communication.
The AIM service provides identity and access management. For this purpose, vf-OS is using the open source software KeyCloak as a modern off-the-shelf solution for managing user access and permissions and it provides a full featured Single-Sign-On environment.
Through the KeyCloak administration interface it is possible to manage users and groups for vf-OS.
The deployment of microservice forms (together with the registry) the asset installation setup. It gets the distributed vApp from the Marketplace, unpacks it, checks the meta-info, and then pushes it to the local registry module. An important part of the meta-info checks is performed for the security design of vf-OS.
The local registry service consists of an off-the-shelf Docker Registry, used to provide valid vf-OS assets to the execution services. As such it forms the Quarantine module as defined in the Security design for vf-OS.
The Portal serves the purpose of showing the installed vApps on the Platform. Through it the user can visualise and open any installed vApp as well as access to the System Dashboard.
The system dashboard was designed to show vAssets statistics and some other relevant information about how it is running in the platform. It is possible to visualise these statistics in real-time and with graphs showing historical data for different features. Although the System Dashboard is part of WP6, its high level of integration with the platform makes it a Platform Service for the purpose of this annex.
All experiments carried out within the vf-OS project have used Amazon Web Services (AWS). Particularly, the instance used follows the t2.large featuring:
Compute units: Burstable
Network performance: Low to Moderate
Frequency: up to 3.0 GHz Intel Scalable Processor
For a safe execution of the vf-OS Environment, it is recommended to apply for an SSD storage of 150 Gb (a bit less is also possible, but not much more).
The installation of the proof-of-concept implementation of the vf-OS Platform is currently performed by downloading a git-repository and running two deployment scripts. It is foreseen that this will be replaced by a binary distribution at the later stage of the project.
Ubuntu 16.04+ although it is best to use the latest LTS version 18.04.1
Install Docker version 18+
Install Node.js 8+, npm 6+
Two options: binary distribution or based on the platform source (From source is currently advised).
The binary distribution consists of a large zip file vfosPlatform.zip, which includes a copy of the quarantine local Docker registry, which stores the binary images of the platform assets.
To start with the binary distribution, you will have to unzip the file. Next you can skip the "From Source" section below, and go directly to the "Configuring the vf-OS Platform" section. You can download the zip file from the GitHub releases page: (external link).
From Source Code
The source code of the vf-OS Platform is accessible at the Developer's Engagement Hub of vf-OS. For doing that, a git download shall be executed:
After downloading the label2manifest tool must first be prepared, through installing the npm dependencies:
First step is to build the docker images for the platform itself. This build process will start a reduced version of the platform to provide access to the vf-OS quarantine local Docker registry in which the assets will be stored before installation.
user@host:~/platform$ ./build.shnpm WARN email@example.com No repository field.npm WARN firstname.lastname@example.org No license field.audited 48 packages in 1.26sfound 0 vulnerabilities67b1b27baf7389de1ed7b169dcaeda228508d5d6989a3f4434eef393cfc3a630Creating network "vfos_default" with the default driverCreating network "vfos_execution-manager-net" with driver "bridge"Creating network "vfos_system-dashboard-net" with driver "bridge"Creating network "vfos_asset-net-00" with driver "bridge"Creating network "vfos_asset-net-01" with driver "bridge"Creating network "vfos_asset-net-02" with driver "bridge"Creating network "vfos_asset-net-03" with driver "bridge"Creating network "vfos_asset-net-04" with driver "bridge"Creating network "vfos_asset-net-05" with driver "bridge"Creating network "vfos_asset-net-06" with driver "bridge"Creating network "vfos_asset-net-07" with driver "bridge"Creating network "vfos_asset-net-08" with driver "bridge"Creating network "vfos_asset-net-09" with driver "bridge"Creating network "vfos_asset-net-10" with driver "bridge"Creating network "vfos_asset-net-11" with driver "bridge"Creating vfos_registry_1 ... doneStarted registry.Sending build context to Docker daemon 146.4kBStep 1/24 : FROM node:alpine .... This will take a couple of minutes ....Stopping vfos_registry_1 ... doneRemoving vfos_registry_1 ... doneRemoving network vfos_defaultRemoving network vfos_execution-manager-netRemoving network vfos_system-dashboard-netRemoving network vfos_asset-net-00Removing network vfos_asset-net-01Removing network vfos_asset-net-02Removing network vfos_asset-net-03Removing network vfos_asset-net-04Removing network vfos_asset-net-05Removing network vfos_asset-net-06Removing network vfos_asset-net-07Removing network vfos_asset-net-08Removing network vfos_asset-net-09Removing network vfos_asset-net-10Removing network vfos_asset-net-11vf_os_platform_exec_control
This will build and install various docker images, which can be checked through the docker image list command. The images of the platform will be named vfos/XXXXX, and the above mentioned six images can be expected. In the "testImages" folder there will be three images as well, in this case packaged in zip files for the internal stub marketplace server.
After this script has finished, you can start the platform through the main start up script, following the common steps below.
Configuring the vf-OS Platform
Before starting you will need to configure the DNS/IP-addresses of the platform: For this you will need to edit the "vf-os.sh" script. For this guide, the server IP to be used is as follows: 188.8.131.52.nip.io.
user@host:~/platform$ nano vf-os.sh...#SET TO TRUE and MODIFY DOMAIN/EMAIL for httpsUSE_HTTPS=/bin/falseACME_DOMAIN_NAME="184.108.40.206.nip.io"#ACME_DOMAIN_NAME="localhost"ACME_EXTERNAL_IP=127.0.0.1ACME_EMAIL="email@example.com"...
In this block, please check and update the ACME_DOMAIN_NAME variable to match your global DNS name pointing to this server. Similarly, you need to update the ACME_EXTERNAL_IP as well, to point to the public ipaddress that your browser can reach. The default settings are good for a localhost setup.
Starting the vf-OS Platform
To start the platform, the following command shall be run:
The first time you run this script it will install runtime dependencies, including the platform assets themselves from the local quarantine repository.
user@host:~/platform$ ./start.sh48071984db7f5ea86ed09403d2cf0e3744494e7b34efd875a092b68d4b494b6cCreating network "vfos_default" with the default driverCreating network "vfos_execution-manager-net" with driver "bridge"Creating network "vfos_system-dashboard-net" with driver "bridge"Creating network "vfos_asset-net-00" with driver "bridge"Creating network "vfos_asset-net-01" with driver "bridge"Creating network "vfos_asset-net-02" with driver "bridge"Creating network "vfos_asset-net-03" with driver "bridge"Creating network "vfos_asset-net-04" with driver "bridge"Creating network "vfos_asset-net-05" with driver "bridge"Creating network "vfos_asset-net-06" with driver "bridge"Creating network "vfos_asset-net-07" with driver "bridge"Creating network "vfos_asset-net-08" with driver "bridge"Creating network "vfos_asset-net-09" with driver "bridge"Creating network "vfos_asset-net-10" with driver "bridge"Creating network "vfos_asset-net-11" with driver "bridge"Creating vfos_registry_1 ... doneStarting vfos_registry_1 ... doneCreating vfos_reverse-proxy_1 ... doneCreating vfos_dashboard_1 ... doneCreating vfos_deployment_1 ... doneCreating vfos_portal_1 ... doneCreating vfos_execution-manager_1 ... doneCreating vfos_aim_1 ... doneCreating vfos_testserver_1 ... done
Other useful links:
You can check if the platform started correctly through the Portal WebGUI: http://localhost
To stop the platform again, the stop script shall be used:
Registration / Login
The open source software KeyCloak is being used as an identity and access management tool for modern applications and services. It helps vf-OS in managing user access and permissions and provides a full featured Single-Sign-On environment.
It is necessary to register and login as a normal vf-OS user for accessing the GUI's (Portal, System Dashboard, etc.). In the current release this registration is available for any user, but future releases will have a more controlled setup in which registration needs to be managed by a KeyCloak administrator. Through the KeyCloak administration interface it is possible to manage users and groups for vf-OS.
For now, it is possible to login as an administrator of the platform or/and just as a user.
How to get the KeyCloak User Management up and running
You need to edit the file "./aim/vf-OS-realm.json" in the platform's working folder. In this file you need to replace lines 450, 451, 456, and 457, to read:
Then, the Platform needs to be re-built by executing the command:
Login as Normal User
It is necessary to register, and login, for an account to have access to all information inside the portal. For this, the "Login" button in the top-right of the navigation bar shall be pressed (Figure 4) taking then the user to the main login screen (Figure 5).
However, if the user wants to create a new account, the "Register" button (from Figure 4) shall be pressed to get to the new user account form (Figure 6).
Figure 4: Navigation Bar
Figure 5: Main Login Screen
Figure 6: New User Account Set-up
Once the user has pressed the "Register" button, their user account will be created, and the user will be automatically logged in. The browser returns to the vf-OS main UI. (portal and/or system dashboard).
Figure 7: Navigation bar when logged in as user Luis
The login button in the navigation bar is now replaced by the logged in user. By clicking on the logged in username, the Portal takes the user to the account management screen, where the account data and password details can be modified.
Figure 8: Account Management Screen
Login as Administrator
To have access to the user management as administrator, the user can login into the Admin Console by accessing the following url:
A login form will be shown, and the user can login as Administrator.
Figure 9: KeyCloak AIM Admin Console Login
By default, the following login credentials can be used:
The platform provides a couple of tools to facilitate the development, distribution, and installation of assets. See image below for an overview of these scripts and each function they provide. In the next few paragraphs each script is described with some examples.
Figure 11: Scripts for the On-Premise Deployment
In the image the following scripts and commands are shown:
Create Asset Code
You can just create your component(s) through any development process you will like, including using the vf-OS Studio. The only vf-OS specific requirement is how to add the correct meta-information for your component. This is documented in vf-OS MetaData format.
Before creating the zip file, you need to build your docker image with the correct labels on them.
NOTE: You can install this docker image directly as an asset into the platform, bypassing the whole quarantine registry. This is a good way to test the labels. Skip directly to section "Install Asset from the Marketplace" for this.
Create Asset ZIP File
To facilitate the creation of the zip file for distributing the assets, the platform provides a tool, called label2manifest.js, which you can find in the root folder of the source distribution and/or in the tools folder of the binary distribution.
This script will take the image from your local running docker daemon, so you need to run the script on the same machine as where you created the asset code.
The script is written for node.js, and has some external dependencies. There is a package.json file in the same folder as the script, which you need to install.
user@host:~/platform$ ls package.json label2manifest.jslabel2manifest.js package.jsonuser@host:~/platform$ npm installnpm WARN firstname.lastname@example.org No repository field.npm WARN email@example.com No license field.audited 48 packages in 1.212sfound 0 vulnerabilitiesuser@host:~/platform$
After installing these dependencies, you can run the script to create the zip file. Below is an example for a docker image called asset-c.
imageid: The name of the main Docker image itself, the one with the labels inside.
deleteArtifacts: Should the script clean up the exported image and the new manifest.json file it created after putting them into the zip file? Simple true or false parameter, defaults to false.
additionalImages: quoted string containing a space separated list of other docker images you like to include into the asset zip file. e.g. asset-c-backend asset-c-config
Through the additional images you can create a multiple image asset, but the meta-information should be placed as labels only in the first image of the set. For these cases it is expected that those labels contain a series of: vf-OS.compose.1.* labels to configure these extra images. (and vf-OS.compose.2.* for the second extra image, etc.)
The script will create a zip file in the folder where you run the script, called imageid.zip, e.g. asset-c.zip.
Deploy Asset to Local Quarantine Registry
In the final setup of the platform, all assets will be installed from the vf-OS Store, by downloading, checking, intermediate storing in the quarantine registry, and installation of the asset into the local docker environment. This is a complex, multi-step process that is annoying and slow during development testing. To ease this for developers, a script is provided, that bypasses many of these steps and can deploy the asset from the zip file, directly into the quarantine repository. This script is called manifest2label.js to mimic its mirror counterpart. This script is provided in the tools folder of the binary distribution, and requires running npminstall for its dependencies.
The product_id field is optional, if none is given a new product will be generated. The version and price fields must be numeric, a string will let the upload fail.
Accessing the vf-Store
The vf-OS Marketplace, aka the vf-Store, is accessible by following the URL (https://vfos-marketplace.ascora.de) which provides access to the various vApps and other vf-OS components that have not been installed with the vf-OS Platform installation.
There is no need to be registered in the vf-Store for browsing the different items published on it, but once a visitor places an order, a user is automatically created using their family name and e-mail address.
After entering the vf-Store, Figure 12 lists the products present ready to be purchased. The tree displayed on the left shows the category of the vf-OS Assets so they are easily searchable.
Figure 12: vf-Store Product Overview
If a user is interested in an vf-OS Asset and wants to purchase it, they simply need to push the button with the price and the text "BUY" next to the Asset desired to be purchased. Then a 4-staged buy process follows, which is shown in Figure 13 to Figure 16. It starts with an overview about the selected product and its costs and the option to change the amount of licences. The second stage is devoted to enter the customer details, which are needed for the payment process. The third stage is to select the payment details, for how the customer wants to pay. There, multiple payment methods are offered by the vf-Store, such as bank transfer, credit card or PayPal. Finally, a confirmation is shown in the screen.
Figure 13: Buy Process - First Step - Product Selection
Figure 14: Buy Process - Second Step - Customer Details
Figure 15: Buy Process - Third Step - Payment Selection
Figure 16: Buy Process - Fourth Step – Order Confirmation
Once the purchase and payment are complete, the asset appears in the section Purchases of the tree menu shown in the left. Below each purchased asset, two links for downloading the asset are provided (see highlighted texts of Figure 17):
Download: Downloads the asset in a local folder. The instructions for installing the asset are shown in "Install Asset Locally" section
Link for the System Dashboard: Copies the link for accessing the asset. The instructions for installing the asset with this information are shown in "Install Asset from the Marketplace" section.
Figure 17: Purchases View
Install Asset from the Marketplace
Through the System Dashboard you can install assets from the vf-OS marketplace. For this you login to the System Dashboard: e.g. http://localhost/systemdashboard.
Figure 18: View of the vf-OS System Dashboard
On the right side of the screen is an overview of earlier installations, showing the progress of their installation.
Install Asset Locally
To get the asset from the local quarantine registry into the actual running platform, requires the generation of the docker-compose file for this asset. This can be done through the REST API of the platform, but to simplify this a script installAsset_._js that does this is provided. This script is provided in the tools folder of the binary distribution, and requires running npm install for its dependencies.
*note: You can also install an Asset directly from your local docker daemon, bypassing the whole quarantine registry. In the example below, you do not include the 'localhost:5000/' part for such images. (Just use the local imageid)
Before running the script, the platform should be running, to provide access to the registry. Run the script like:
user@host:~/platform$ installAsset.js localhost:5000/asset-a trueGot metadata from docker image: localhost:5000/asset-cPlatform reloaded. user@host:~/platform$ ls .compose0_platform_compose.yml 1_networks_compose.yml 3_asset-c_compose.yml docker-composeuser@host:~/platform$ docker container listCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESccb18f1062d8 localhost:5000/vfos/deploy "/usr/src/app/entryp…" 23 seconds ago Up 19 seconds 9000/tcp vfos_deployment_17cda48ac56a4 localhost:5000/vfos/system-dashboard "npm start" 23 seconds ago Up 18 seconds 9000/tcp vfos_dashboard_1067dd4ec6b0a localhost:5000/vfos/test-server "npm start" 23 seconds ago Up 15 seconds 9000/tcp vfos_testserver_10afa60d16778 localhost:5000/vfos/exec-manager "npm start" 23 seconds ago Up 17 seconds 9000/tcp vfos_execution-manager_1f16f1a26a87c localhost:5000/asset-c "npm start" 23 seconds ago Up 15 seconds 9001/tcp vfos_asset-c_1789b38d393a8 localhost:5000/vfos/aim "/opt/jboss/tools/do…" 23 seconds ago Up 20 seconds 8080/tcp vfos_aim_191187164867b localhost:5000/vfos/portal "npm start" 23 seconds ago Up 21 seconds 9000/tcp vfos_portal_1c06837648ca6 traefik:latest "/traefik --api --do…" 23 seconds ago Up 12 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:8080->8080/tcp vfos_reverse-proxy_1f53130f4f819 registry:2 "/entrypoint.sh /etc…" About an hour ago Up About an hour 0.0.0.0:5000->5000/tcp vfos_registry_12bfa81621399 docker/compose:1.22.0 "/bin/sh -c 'cat /de…" About an hour ago Up About an hour vf_os_platform_exec_control
As you can see in the example, the script creates a docker-compose file, called3_assetId_compose.ymlwhich is included by the reload of the platform.