Introduction to the TeamDrive Web Portal¶
TeamDrive Web Portal Overview¶
The TeamDrive Web Portal consists of a number of components.
Firstly, the TeamDrive Web browser interface (ie. the TeamDrive Client interface that runs in a browser) is served by Apache.
The TeamDrive Web Portal Administration Console and the Web Portal
authentication API is served dynamically by the Yvva Apache
A list of Docker containers and other administrative information is stored
in a Management MySQL Database called
webportal. This database must be
accessible by all components of the Web Portal.
In addition, a Docker-based environment runs the TeamDrive Agents which serve the TeamDrive browser interface. A TeamDrive Agent is faceless TeamDrive Client which provides a HTTP-based Rest API for the purpose of accessing an TeamDrive user account.
Depending on the scale of an installation, all components: Apache, MySQL and Docker may run on one machine or on separate machines. Docker itself may run on a cluster of machine, however setting up such a configuration is not part of this documentation.
TeamDrive Hosting Basics¶
A TeamDrive Web Portal requires a unique domain name. The domain
name is basically the URL for the TeamDrive users that access the Web Portal.
This domain name is stored in the
WebPortalDomain system setting.
The same domain name is also used to access Administration Console by
/admin/ to the base URL:
Once the TeamDrive Web interface has been service, further calls from the browser will be redirected to the appropriate TeamDrive Agent running in a Docker container. In order to do this, an Apache rewrite rule is installed which allows Apache to act as a reverse proxy, forwarding calls to the TeamDrive Agent.
If your setup uses a load balancer before the Apache instance, then it may be possible to have the load balance perform the redirect instead of first sending the message to Apache. The Apache rewrite rules that perform this task are the following:
RewriteRule "^/agent-([0-9]*)/(.*)" "http://127.0.0.1:$1/$2" [P] ProxyPassReverse "/" "http://127.0.0.1/"
Check the Apache documentation for a description of what these rules do in order to implement an equivalent transformation using your load balancer.
As mentioned above, the Docker system is responsible for running multiple TeamDrive Agents instance in containers. A container with a agent is created for each user session.
The users data is not stored in the container itself. Instead, the container mounts a directory in the host machines file system.
The root mount point for all containers is
\teamdrive\ by default.
This path is stored in the
ContainerRoot system setting. The username
of the user is added to this path to produce the mount point for
each individual container. For example the user for user “td_user_1”
Under this directory, the TeamDrive agent stores the “meta data” (file names and directory structure) of the Spaces that have been entered, as well as a disk cache for any files in transit.
The Space data stored by the TeamDrive Agents is stored in unencrypted form. For this reason, security of the Docker host system is extremely important.
Background Tasks Performed by
td-webportal process is a service that executes background
tasks scheduled by the Web Portal.
It uses the Yvva daemon
yvvad to run the following background tasks at
a definable regular interval:
Remove Idle Containers:
The purpose of this task is to remove containers that are no longer being used.
When a user session times out, the container running the associated TeamDrive Agent exits (stops executing). When this happens the container is not removed. It remains in the system and is simple restarted when the user logs in again.
This task removes containers that are unused for a certain amount of time (indicated by the
IdleContainerTimeout). This period should be longer than the regular user session timeout.
Containers that are removed are automatically recreated by the Web Portal when the user logs in again. The only difference is that login process takes a little bit longer because the container must be created and then started, instead of just restarted if the container already exists.
Delete Container Storage:
This task removes container data if a container is unused for a certain period of time (as specified by the
ContainerStorageTimeoutsetting. The container data is the data stored under the
ContainerRootdirectory for a particular container, for example: the directory
\teamdrive\td_user_1for the user “td_user_1”.
The purpose of the task is to free up unused disk space.
If a user logs in again after the container data has been deleted the user will find that all of his Spaces have been set to “Inactive”. This means that he has to enter a Space again in order to access the data. Since this could inconvenient and time consuming the
ContainerStorageTimeoutshould be set to a fairly large period, for example 1 month.
Remove Old Images:
The purpose of this task is to remove containers so that the TeamDrive Agent version used by the Web Portal can be upgraded.
The TeamDrive Agent running in a container is never updated “in place”. Instead, the Web Portal waits for a container to be removed, and then the new TeamDrive Agent version is used when a new container is created.
This task specifically removes containers that are running an old TeamDrive Agent image. The current (and new) TeamDrive Agent image to be used is specified using the
There are a number of settings which control the behaviour of this task:
RemoveOldImagesmust be to True to enable this task.
OldImageTimeoutis the time, in seconds, that a container with an old image must be idle before it is removed. Zero means the container is removed, even if it is running.
OldImageRemovalTimeis used to specify when containers with old images should be removed. You can set it to “now”, to remove the containers immediately, if set to “never”, then containers are only removed if the OldImageTimeout is exceeded. This setting value can also be set to a time (e.g. 03:00, format: hh:mm), or a date (format YYYY-MM-DD hh:mm).