Convier at a glance

Convier runs as a Docker container entirely within your organization’s environment, e.g. as an AppService or Virtual Machine in Azure or on-prem using providers like VMWare or Citrix. No data leaves your network. Convier runs in your existing Azure tenant/organization. Convier can run under almost any conditions, some common patterns are illustrated below:

Common patterns

image

  1. Both the Internet browser and Convier runs on the same virtual machine that the user logs in to
  2. The Internet browser and Convier runs in different virtual machines within the same isolated network, e.g. Citrix
  3. Convier runs in a firewalled virtual machine that is accessible from the Internet browser running the user’s computer. The virtual machine runs on-prem or in your private cloud.

Convier can run with an embedded OIDC provider for user authentication and authorization, but that is not recommended.

System requirements

Convier is designed to run with minimal resources within a Docker container. It consists of a server component, and a browser web app that is provided to users by the server.

Server

Hardware

The primary requirement is a physical or virtual machine capable of running Docker. A linux host is preferred, but not required. The Docker container will use storage mounted on the hardware, or a provided databaee, to persist configuration. No customer data is stored within Convier.

Resources:

Concurrent users RAM CPU cores Disk space
1 - 2 4 2 4
2 - 10 8 4 8
11 - 30 16 8 16
31 - 50 20 16 24

Client:

  • High screen resolution is recommended (minimum 1920 x 1080)
  • A modern Internet browser
  • At least two CPU cores
  • 4GB of RAM

The web browser must allow cookies in order for Convier to maintain user sessions.

Firewall

A high-level overview of the application architecture with required connection points:

image

Inbound

  • The user needs to be able to access the URL of the Convier server running within the organization’s environment, either directly or through a VDI like Citrix

Outbound

  • An OIDC provider like Aure AD for user authentication and authorization (If none are available we can provide one)
  • The Convier private Docker registry to download software updates (currently https://docker.convier.com)
  • Databae connections to relevant data warehouses
  • HTTP connections to relevante APIs
  • (Optional) Database connection(s) to store application configuration and/or audit logs

Running Convier

Convier has two different relase tracks: “latest” and “stable”, where latest get new features more quickly. Customers choose which they want to follow, and it may be changed at any time.

Initial installation

The recommended way to run Convier is using Docker Compose, A docker-compose.yml file with relevant configuration and relase track will be provided at the start of the project.

Running

docker-compose up -d

Upgrade

docker compose pull && docker compose up -d

Audit logging

The system logs high level event types, like search, save and configuration changes. These audit events include, with parameters. (All events include datetime and event type, access logs also include user IP address, audit logs include user ID). The audit log may be stored internally within the application, or in a provided database.

Permissions

Within the Convier application, each user is assigned two different roles: One for the application as a whole, and one for each project. These roles are either OWN, MANAGE or READ. The application roles are determined by the authentication provider, for example Azure AD.

  • The READ role is only able to access data, and make individual configuration changes that can not be shared with others without approval. They can not add external data source connections.
  • The MANAGE project role is able to share configuration changes with others, and is usually reserved for Convier personel and customer subject matter experts. Unless they also have the application role MANAGE, they can not add external data source connections. Application role MANAGE can add external data sources (limited by firewall settings) and also track high-level application usage.
  • The OWN project role can do the same as the MANAGE project role, but can also assign project roles to others.