FAQ
General FAQ¶
- Q: What are the deployment options?
Please refer to this Deployment options document that outlines our deployment options
- Q: How does on-prem/self-hosted installation work, and how are updates done for self-hosted deployments?
Our on-prem or self-hosted installation offers various deployment options, such as containers or single-server/all-in-one. We provide comprehensive documentation and credentials, enabling you to access our repositories for downloading and installing our software. The typical installation process is straightforward and takes approximately 15 minutes.
- Q: How difficult and time-consuming is the upgrade process and managing the application?
Updates for on-prem deployments are conducted using Linux package managers like apt or yum/dnf. Your DevOps team would simply need to update the packages from our private repository and restart the necessary services. This process is not difficult and is generally user-friendly.
Regarding maintenance, we estimate 5 hours per month mainly for addressing user issues and troubleshooting. However, this time may vary based on your specific deployment, and in some cases, it could be even less.
Comet Security Installation FAQ¶
Auth¶
Out of the box, comet provisions itself using a basic auth method that’s backed by the MySQL database for user and password storage. Passwords are stored as md5 encrypted strings and the database engine itself can and should be configured to disallow passwordless access.
Should you be using an authentication provider in your organization already, Comet can integrate with it, as it offers full support for SAML, oAuth and OIDC authentication, as well as support for (almost) any directory service you may be using. We provide documentation for most of our supported options online. Should you not see your requested auth solution please speak to the deployment team and we can either produce or update any missing documentation, or have the backend team implement any new feature requests you may have.
SSL¶
Comet does not require SSL to get started and supports plain HTTP.
However, it offers a low-overhead way to get started with SSL quickly using Let’s Encrypt if you are not already managing your own SSL certificates in another way. Information on how to set this up is provided in our installation documentation that can be accessed using a valid comet license key.
When SSL is enabled it will be used for all http and websocket connections the application makes in the course of its normal operation. This would include all browser requests, as well as any requests the SDK makes to the application.
Encryption at Transit¶
When SSL is enabled in-app, Comet will refuse connection over unencrypted http and websocket streams. All communication between user and app, as well as SDK and app, will be completely encrypted.
Any and all credentials for Comet as well as any application dependencies for comet are configured in /etc/default/comet-ml.yml by default. To edit this file, run cometctl aio update-config You can configure comet to read sensitive credentials from external key-value store such AWS’s Secrets Manager or Azure’s Key Vault to minimize the number of sensitive credentials you are storing in plain text.
Encryption at Rest¶
When storing your experiment products in S3, you can enable server-side encryption on your bucket to provide an added layer of data security. If you are storing your experiment products on-disk, LUKS or an alternative can be used to provide full disk encryption. Comet does not require any application specific configuration to work with LUKS.
Default Firewall Rules¶
For an all in one installation the following ports are required to be open:
80/443 - For connections to the application via the browser and using the SDK. This port can be restricted if you are only allowing comet to be accessed from a company intranet or VPN. Keep in mind that the machines that run the experiments will need to be whitelisted in order for them to be able to submit their relevant metrics to comet.
We also strongly recommend you allow an administrator access to ssh to the machine on port 22 to allow for maintenance and upgrade operations.