# Introduction to JovianX ## What is JovianX? The **JovianX Platform** is a control plane for SaaS and cloud applications, allowing to build, and operate SaaS offerings, and fully managed cloud services. JovianX is built for companies who are looking to start a **new SaaS business** or create a **cloud version of an existing software** product, without all the heavy investment it usually requires. JovianX Platform provides a management console, with a rich set of services to build, run and manage a SaaS product. Including: application Management, Payments and Billing, Subscription Management, Multi-Tenancy, Application Life-cycle Management, Monitoring and Logging, Hosted self-serivce Signup, User Signup Designer, Authenticated application end-points and much much more. JovianX is designed for *cloud architects,* *SaaS business leaders,* *DevOps* and *Site Reliability Engineers (SRE)*. It allows cloud architects to design, build and manage a multi-tenant SaaS solution, it allows Site Reliability Engineers to manage service levels([SLO](https://landing.google.com/sre/sre-book/chapters/service-level-objectives/)) and operate the SaaS Solution, and lastly, it allows SaaS business leader to manage all the business aspects of a SaaS product, including defining and managing offering plans and provides dashboards for monitoring the SaaS business results (MRR, ARR, LTV, Churn, CaC, etc'). ![](/files/-M2yarVp9jFdum7eoteR) ## How does it work? JovianX provides a hosted customer console that allows your customers to sign up for your cloud service. When a new account (your SaaS customer) signs up, JovianX creates all needed cloud resources for that account and creates a billing subscription for a chosen billing plan and selected options. ![](/files/-M_zqUoI2kV-JERtIJEN) 1. Your customer signs up. 2. JovianX creates the resources and deploys the application needed for the new account. 3. JovianX creates a billing plan, based on user-selected billing plan and options. JovianX uses an [Application Blueprint](/documentation/jovianx-application-blueprint) to create the needed cloud resources for a new account. The application Blueprint is a package (a tar.gz file) that contains an Application Manifest(a file named `jovianx.yaml`) and defining the rescues (Kubernetes Helm package, or other cloud managed services such as AWS DynamoDB, Cloud SQL for example) needed for new account creation. # Getting Started with JovianX #### Table of Content 1. [Create and upload application blueprint](/getting-started-on-jovianx#step-1-create-and-upload-application-blueprint) 2. [Setup subscription plan](/getting-started-on-jovianx#step-2-setup-a-subscription-plan) 3. [Configure basic settings](/getting-started-on-jovianx#step-3-basic-settings) 4. C[reate customer account](/getting-started-on-jovianx#step-4-creating-customer-accounts) ### 1. Create and upload the application blueprint To get started creating your managed SaaS with JovianX, create your first [application blueprint](broken://pages/-LdZT-OS5JBfU8s00sNW). You can start by cloning the Hello SaaS World example blueprint from [GitHub](https://github.com/jovian-x/hello-world-saas-app). ```bash git clone git@github.com:jovian-x/hello-world-saas-app.git ``` #### Step 1 - Review application manifest: Review the application manifest file (a YAML file named [`jovianx.yaml`](https://github.com/jovian-x/hello-world-saas-app/blob/master/jovianx.yaml)). The application manifest has 2 main sections: the first is `Components` which declares service components with their properties, and the second is `settings_descriptors` which allows end-users to choose settings and control properties on signup. To review the application manifest file use cat command: ```bash cat hello-world-saas-app/jovianx.yaml ``` {% code title="hello-world-saas-app/jovianx.yaml" %} ```yaml # JovianX API Compatibility # v1 jovianx_api_version: v1 # Name of this SaaS application # string application_name: hello-world-app # version of this JovianX blueprint # semantic versioning version: 1.0.0 ... ``` {% endcode %} #### Step 2 - Create application blueprint archive An application blueprint is a `*.tar.gz` archive that contains an application manifest file(`jovianx.yaml`) in it's root directory, and also includes all the helm chart directories referenced in the application manifest `Jovianx.yaml` file. Review the files in the blueprint: ```bash tree hello-world-saas-app/ hello-world-saas-app/ ├── jovianx.yaml ├── LICENSE ├── mongodb-chart │ ├── Chart.yaml │ ├── values.yaml │ └── ... ├── node-chart │ ├── Chart.yaml │ ├── values.yaml │ └── ... ├── README.md ... 7 directories, 39 files ``` Create a `tar.gz` archive with the application manifest file(jovianx.yaml). ```bash cd hello-world-saas-app/ tar -czvf blueprint.tar.gz jovianx.yaml node-chart/ mongodb-chart/ values/ ``` {% hint style="info" %} **NOTE:** Make sure the the application manifest file (file named`jovinax.yaml` is in the root of the archive file, and also that the archive includes all referenced helm charts as non-archived directories. {% endhint %} {% hint style="success" %} You can name the blueprint archive any name you like, the best practice is to include the application name and version in the filename, i.e \`myapp\_blueprint\_4.13.0.tar.gz\`. {% endhint %} #### Step 3 - Push the application blueprint to JovianX Push the application blueprint to JovianX via the UI, or via API. {% tabs %} {% tab title="Push Blueprint via API / CURL" %} To push the blueprint via the API using Curl command: ```bash curl -u ':' -F 'file=@blueprint.tar.gz' 'https://.jovianx.app/api/v1/upload_blueprint' ``` {% hint style="info" %} **NOTE**: You can find your `ACCOUNT_API_KEY` and `ACCOUNT_API_SECRET` in the blueprints page under Upload a new Blueprint card. You can also integrate the push operation with your CI workflow. {% endhint %} {% hint style="info" %} **NOTE**: You can also set the blueprint as ACTIVE by adding the querystring `?make_default=true` to the API path. {% endhint %} {% endtab %} {% tab title="Push Blueprint via Web UI" %} To push the application blueprint via the Web UI: 1. Navigate on the side-menu to `Application > Blueprints`. 2. Click on the top card titled `Upload a new Blueprint`. 3. Click on button `Choose blueprint tar.gz file`
![Side Menu > Blueprints > click on "Upload a new Blueprint" card](/files/-M3_nGqx4JqEPICz9w_i) {% endtab %} {% endtabs %} ### 2. Setup a subscription plan A plan determines the recurring period of a subscription and can determine how much to charge for each billing period, it can also enable or disable the trial, and determine the trial period. #### **Create a plan:** 1. Using the side-meue navigate to `Plans` 2. Click on `Create new Plan` 3. Choose plan settings and enable Trial 4. On the bottom of the screen click on `Create new plan Version` 5. Review the newly created plan in plans list ![2. Create a new billing Plan](/files/-M3asBClgWHOlWL6SNXj) ![3. Configure billing plan settings ](/files/-M3aspSM0KM0-4DYI5lZ) ![5. Review plans](/files/-M3atQV-h9AZN43_M7L7) {% hint style="danger" %} **NOTE**: You must have at least one plan in your account. {% endhint %} {% hint style="success" %} **NOTE**: To enable "Require payment details on subscription", first enable payments and configure your PayPal account by navigating to `Settings > Payments > Enable PayPal.` {% endhint %} ### 3.Basic settings In the settings section you can configure many aspects of your managed service, including integration with a private Docker registry, Cloud DNS, cofngire your Kubernentes KUBECONFIG files, define the behavior of the customer console ![Configure automated email notifications](/files/-M3ayydfiElhhJ6pBg3I) ![Configure the hosted customer console](/files/-M3azCBlV27jLEoSn_ri) ### 4. Create a customer account Navigate to the customer console and create an example test account ![White-label Hosted Customer Console](/files/-M3aztNQNohVJYdJU1Q2) ### # Release Notes ## 1.27.0-20210731 #### New Features: * Blueprint: Application Metering - The allows to meter application-specific consumption metrics. !659 * Blueprint: Manual Hooks - Allows defining and executing predefined procedures on accounts. !665 * Blueprint: Get application users to hook, allows showing application internal users in the users' tab. !666 * Kubernetes health: Kubernetes health detection now uses cluster health commands and shows Kubernetes internal services health !673 * Show helm release name, and target cluster for deployed components. !677 * Added Pods restart button. !676 * Vendor Console Branding Customization: the vendor ops console now supports branding customizations, allows to set of custom logos, and titles. !680 * Added account and infrastructure analytics !679 * Added Billing settings and plans management !674 * Added account subscription settings !670 * Added application main entry point to the accounts list !691 * Improved mechanisms for Celery scheduled tasks !686 * Improved automated tests !675 * Updated Hello World example !672 #### Bug Fixes: * Fixed Helm parameters now don't show account creator passwords !681 * Fixed Cluster Status Detection Bug !684 * Fixed account analytics calculation bug !687 * Fixed DB migration indexes failure !688 * Fixed errors in account metering URL !689 ### 1.26.0-20210621 New Features: * Added support for BlueSnap billing provider [!651](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/651) * Cluster status detection and notification [!657](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/657) * Application Stacks full hooks support [!618](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/618) * Added force delete option for accounts when the app cluster is down [!662](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/662) * Added hooks status and Service LB status to application status indicator [!664](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/664) * Customer console now prevents login to suspended accounts [!669](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/669) Bug Fixes * Fixed application status detection periodic task priority [!663](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/663) * Fixed redundant information from the account creation event [!655](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/655) * Fixed login screen react warnings [!661](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/661) * Fixed Kubeconfig upload button spinner [!667](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/667) * Fixed application status detection gets stuck on "Starting" on custom hook failure [!668](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/668) ### 1.25.2-20210528 Bug Fixes: * Fixed upgrade account bug prevents account upgrade [!660](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/660) * Fixed retrieval of clusters list if there are no clusters [!658](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/658) * Fixed endless email loop of email\_notification\_before\_trial\_ends [!654](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/654) ### 1.25.1-20210519 Bug FIx: * Fixed cluster status detection issue [!656](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/656) ## 1.25.0-20210518 New Features: * Added ability to create custom pages in the Self-Service Customer Console [!648](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/648) * Added optional Application Control Pane to the customer console [!643](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/643) * Added ability to set Blueprints as "Available" and not available [!633](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/633) * Added support to make Blueprint `settings_descriptors` optional [!622](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/622) * Added Kubernetes cluster status detection [!637](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/637) * Added Password complexity indicator [!647](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/647) * Added events for account approval in account events. [!634](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/634) * Added support to the backend to use MongoDB Replicasets [!646](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/646) * Added support to the backend to use MognoDB Connection String [!652](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/652) Bug Fixes: * Fixed 'Agree to terms' is now a checkbox [!645](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/645) * Fixed Password Reset notification [!631](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/631) * Fixed Agent Download source URL [!642](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/642) * Fixed Kubernetes API calls validate cluster availability [!644](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/644) * Fixed Update time formatting [!632](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/632) * Fixed Removed obsolete server configurations [!636](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/636) * Fixed redundant Stripe API calls [!640](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/640) [!641](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/641) * Fixed verification for Scale-Down api calls [!635](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/635) * Fixed Typo in `lauch_type` tag [!638](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/638) * Fixed view of Dashboards with failed API calls [!639](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/639) * Fixed validation to Backend for MailGun API availability [!649](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/649) * Fixed application status check-raises error on disabled components [!653](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/653) ### 1.24.1-20210411 Bug Fixes: * Fixed plan price is shown on the customer console when billing is disabled [!620](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/620) * Fixed Kubernetes clusters view UX/UI [!621](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/621) * Fixed Blueprints list separation for Accounts and Stacks [!623](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/623) * Fixed Billing tab in account moved position [!624](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/624) * Fixed Redirect to app on login [!628](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/628) * Fixed Helm custom timeout settings [!625](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/625) * Fixed \[Stacks] Display stack details [!612](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/612) * Fixed Start application on vendor console after account creation [!626](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/626) * Fixed Rest password with tenant ID. [!629](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/629) ## 1.24.0-20210324 New Features: * Added ability to enable manual account approval before launching the application of the account. !619 Bug Fixes: * Fixed Stacks upgrade process !611 * Fixed Subscription card is shown when the account is ACTIVE !613 ### 1.23.1-20210309 BugFixes: * Fixed Scale down and scale up using API key !617 * Fixed customer console label for account naming convention !616 ## 1.23.0-20210308 New Features: * Settings screen can now become an optional step in customer console signup [!615](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/615) Bug Fixes: * Fixed dashboard PVC on empty volumes with AWS [!610](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/610) * Fixed Endpoints don't show details on customer console and vendor console [!614](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/614) ### 1.22.2-20210228 BugFixes: * Fixed Paypal update subscription price ### 1.22.1-20210225 Bugfixes: * Fixed vendor console incorrect routing !608 * Fixed customer console crashes !609 ### 1.22.0-20210223 New Features: * Added hooks execution to create event messages [!600](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/600) * Added blueprint version as blueprint variable {{ account://application\_version}} [!603](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/603) * Added support for Stripe and PayPal, Added customer console billing dashboard [!447](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/447) * Added billing pricing page [!605](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/605) Bug Fixes: * Fixed extra API calls in customer console dashboard which now loads dashboard 5X faster. [!604](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/604) ### 1.21.2-20210210 BugFixes: * Fixed validate end user API [!599](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/599) * Fixed error messages UI [!598](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/598) * Fixed customer console redirect to signup settings [!602](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/602) * Fixed external links in customer console custom menus [!601](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/601) ### 1.21.1-20210209 BugFixes: * Fixed start application from Vendor Console doesn't start. [!588](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/588) * Fixed complete signup form for end-users. [!596](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/596) * Fixed update first name last name rendering. [!597](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/597) ### 1.21.0-20210204 New Features: * Authentication based on Google Identity Platform [!570](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/570) * Extended endpoint information for accounts [!581](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/581) * Updated Octant to 0.16.3 [!584](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/584) * Customer custom signup information can now be used in webhooks and email templates [!587](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/587) * Added `?preventRedirect=true` QueryString to the customer Console to actively prevent redirection into the application [!593](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/593) * Account creation now uses FirtName LastName instead of FullName [!588](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/588) Bug Fixes: * Fixes new account error messages [!582](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/582) * Fixed email template defaults [!583](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/583) * Fixed customer console React.JS safly destruct objects [!585](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/585) * Fixed handle of long hook execution [!580](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/580) * Fixed end-user account creation email uses the wrong URL [!589](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/589) * Fixed Customer Console now redirects to entry point URL [!591](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/591) * Fixed UI crashes on automation "Add Header" button [!594](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/594) ### 1.20.1-202110110 Bug Fixes: * Fixed waiting for account creation clouds annimation [!579](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/579) ### 1.20.0-202110110 New Features: * Adding management for AWS EKS [!533](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/533) * Send custom email notification on version upgrade [!556](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/556) * Added ability to create Account-level notes [!568](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/568) * Added Application Stacks [!537](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/537) * Added message container splash screen clouds background [!575](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/575) Bug Fixes: * Fixed prevent upload of blueprint without semantic version [!559](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/559) * Fixed Email notifications now respect trial end date changes [!560](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/560) * Fixed Lock PyJWT to version 1.7.1 [!572](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/572) * Fixed button colors for vendor and customer consoles. [!574](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/574) * Fixed UI console errors [!576](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/576) * Fixed UI error handling for blueprint upload [!577](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/577) * Fixed flashing screen of initial load for the Kubernetes UI. [!578](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/578) Internal Changes * Handle account creation via backend task instead of API [!566](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/566) * Celery tasks are now executed based on priority and include expiration [!567](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/567) * API timeouts are now configured via environment variables [!573](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/573) ### 1.19.3-20201115 Fix CI ### 1.19.2-20201115 Bug Fixes: * Fix upload blueprint URL in UI [!561](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/561) ### 1.19.1-20201111 Bug Fixes: * Adding missing tests manual execution. [!558](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/558) ### 1.19.0-20201110 ### New Features: * Tests results are shown per blueprint, it is now possible to run tests via UI. [!544](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/544) * Reorganize main menu. [!550](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/550) Bug Fixes: * Fixed instructions for creating a new blueprint in the Blueprints UI. [!551](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/551) * Fixed redundant error messages for applications in Running state. [!552](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/552) * Fixed member invitations automatic cleanup. [!553](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/553) * Fixed continuous account change to active. [!557](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/557) * Fixed dynamic parameters of non-existing components now show proper error messages in events. [!555](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/555) ### 1.18.0-20201029 New Features: * Variable Secrets that can be used in the blueprint [!517](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/517) * Update octant to 0.16.1 [!526](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/526) BugFix: * Fixed DNS creation [!546](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/546) * Fix UX on Variable Secrets ### 1.17.1-20201026 BugFix: * Adding helm3 home for celery ### 1.17.0-20201026 New Features: * Support Helm3 [!491](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/491) * Cluster providers automatic tagging [!539](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/539) * Detailed error messages in app status dispaly [!531](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/531) * Update UX styling [!542](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/542) Bugfix: * Fix deletion of applications with Helm3 [!541](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/541) * Fix React.JS Linter issues [!540](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/540) ### 1.16.2-20201007 Bugfix: * Fixed error await message when viewing shared components. [!535](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/535) ### 1.16.1-20201005 Bugfix: * Freeze celery to version 4.4.7 ### 1.16.0-20201001 Main Themes: * Application Status Detection * New Hooks * Azure Kubernetes Service management improvements New Features: * UI: Vendor Console: Detailed application status [!520](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/520) * Keep track of app status after it started [!509](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/509) * Adding icon updates to app state details [!524](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/524) * Application live status detection [!525](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/525) * Add failure-threshold to the blueprint [!532](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/532) * Hooks: Add new hooks preupgrade, post\_upgrade, delete [!515](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/515) * Azure: Add and remove node pools [!518](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/518) * Azure: Adding VM Size Labels [!522](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/522) * Azure: cluster node pool details UI part [!530](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/530) * Email notifications on app error status [!513](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/513) Bug Fixes: * Resolve "Custom Menu breaks the customer console" [!519](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/519) * "Changing trial date should also change the accounts billing plan trial date" [!516](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/516) * Vendor Console > Account >App - shows all app objects twice!527 * App state details view flickers with wrong account information [!528](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/528) ### 1.15.1-20200816 Bug-fixes: * Added console logs for kubeconfig dumping * Octant embeded iframe is now 100% ## 1.15.0-20200802 New Features: * 513-blueprint-output-in-dry-run * 332-log-event-when-service-not-found * 515-custom-menu-items Bug Fixes: * Fixed run-tests name generation [!501](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/501) [#159](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/issues/159) (closed) * Fixing auth URL to accept any subpaths * 514-fix-on\_failure-property-of-hooks * 510-broken-blueprint-does-not-set-error-app-state * 517-skip-blueprint-error-on-customer-deletion * 520-fix-simple-line-icons-css-build ## 1.14.0-20200727 **New Features:** * Blueprint tests !496 #159 * Blueprint dry-run mode !499 #159 * Add Kubernetes Management(Octant) UI !498 #508 #483 * Support "Textarea" as setting\_descriptor !477 481 * Helm\_set is optional, setting\_descriptor is optional !478 #330 * Prevent Blueprint removal for live accounts !486 #161 * Events now shown as YAML instead of JSON !493 #428 * AKS: Azure Kubernetes Service(AKS) management, it is now possible to connect to existing AKS clusters, initialize helm, and !472 #473 * AKS: It is now possible to create new AKS clusters from the JovianX UI. !484 #492 * Hooks support environment variables !488 #498 * Hooks support for service\_account\_name and namespaces !489 #499 * Accept access\_token as an alternative to Auth Bearer token !487 #497 * Auto-sync octant Kubeconfigs with JovianX loaded Kubeconfigs #486 * Support Kubernetes 1.16+ - Move to Kubernetes stable API Apps/V1 instead of AppsV1beta2Api!480 #487 !496 #505 **Bug Fixes:** * Fixed account page when not settings\_descriptors defined #512 * Fixed run-tests name generation !501 #159 * Fixed save target context/cluster on deploy-time, show app from saved context. !482 #488 * Defined Kubernetes and Helm timeouts to 30 seconds !494 #509 * Fixed access token via auth subpath !485 #496 ### 1.13.2-20200624 Bug Fixes: * Validate Kubeconfig file on upload [!459](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/459) * Account deletion stuck in Terminating [!460](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/460) * Create an event on account status change [!461](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/461) * check\_application\_launch\_status crashes on incorrect DNS configuration [!462](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/462) * Events should be able to handle events with binary data [!464](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/464) * Node utilization dashboard breaks when no metrics coming from Kubernetes API [!466](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/466) * Change Blacklist wording to Blocklist [!475](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/475) New Features * Set endpoints by settings\_descriptors [!471](https://gitlab.com/jovianx/jovianx-isv-portal/-/merge_requests/471) ### 1.13.1-20200512 Blueprint: It now possible to set application `endpoints` via blueprint `settings_descriptors` ```yaml settings_descriptors: - name: ha display: 'Enable High availability cluster' description: 'This option will replicate your application across the world. It will drastically reduce latency' input_type: checkbox default: false select_options: - name: true components: - name: node-component helm_set: - key: ha0-manager value: true # added new directive `endpoins` under component setting_descriptors. endpoints: - name: 'application_web_interface' service_name: node type: main_entry_point entry_point_url: 'http://{{ account://end_company }}.jovianx.app/ha-true' label: 'application_web_interface' port: 80 dns: '{{ account://end_company }}.jovianx.app' ``` ## 1.13.0-20200510 New Features: * Account status: Accounts can now easily change the account status from Trial, Active and Suspended. [!441](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/441) * Application scale-down: JovianX now allows manually scale-down and scale-up an account application. Application Scale-down updates the controller replicas to 0, and Scale-up returns the replica count to the state it was before scaling down. [!442](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/442) * Application controller status: Show Kubernetes application StatefullSets, Deployment, Jobs, and Replicasets. [!431](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/431) * Event Automation: Variables are now supported in the webhook URLs. [!444](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/444) * User Invite Blacklists: User invitations now respect the email blacklist. [!454](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/454) * Kubernetes Kubeconfig is now optional. [!445](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/445) Bug fixes: * Better handling of Helm communication errors with Tiller. [!446](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/446) * Fixed accounts list sorting. [!451](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/451) * Fixed Plans page, settings prices for feature flags. [!448](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/448) * Fixed application readiness check. [!452](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/452) * Fixed trials date display. [!453](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/453) * Fixed Job completing check status. [!455](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/455) * Updated icons and UI titles. [!456](https://app.gitbook.com/jovianx/jovianx-isv-portal/-/merge_requests/456) ### 1.12.2-20200412 #### Bug Fixes: * Resolve "Change application manifest(jovianx.yaml) to root from ./ in blueprint". !440 #423 ### 1.12.1-20200411 #### Bug Fixes: * Fixed: Added support for commas in helm parameter values. !439 #420 * Fixed: Added an event that includes the generated helm release name to the account events. #387 * Fixed: Added an event with an error message when starting an application with a non-existing context. #412 * fixed: post\_install is now part of the application "starting" phase. #405 * Fixed: DNS wildcards are now not deleted on account deletion. #339 * Refactoring of vendor and customer-company internal business logic. !438 #416 ## 1.12.0-20200408 #### New Features: * Resolve "Upload multiple Kubeconfig files" !351 * Resolve "Blueprint Linter" and add force\_update !423 * Resolve "Trigger Webhooks based on system events" !425 * Improve plans view !426 * Improved UX for the accounts list !427 * Resolve "Vendor Console: Delete account confirmation show account name" !429 * Resolve "Blueprint: choose component context" !437 #### Bug Fixes: * Fixed Error message on kubeconfig file load !436 #418 (closed) * Resolve "Accounts not switching to Running" Added reties for helm errors in App status check !424 * Fix styles for Accounts page !428 * Change title crash to error !433 * Resolve "change kube\_context\_conf to kube\_context" !434 * Fix header field !435 * Error message on kubeconfig file load !436 ### 1.11.5-20200308 #### BugFixes: Fixes Update application fails if there's no admin\_email and admin\_password in the blueprint !422 #402 ### 1.11.4-20200305 #### BugFixes: Updated Flask and Gunicorn to last versions !421 #401 ### 1.11.3-20200227 #### Bug Fixes: Fixed update application with dot('.') in the blueprint are not started successfully !419 #392 Fixed agent pull mechanism from external sources !420 #393 ### 1.11.2-20200224 #### Bug Fixes: Fixed automated email notification "X days after signup" reminder not sent !414 #386 Fixed application status not changing to 'running' when helm does not have a supported controller object(ie when the helm chart doesn't have any of the following objects: Deployment, StatefulSet, ReplicaSet, Service). !415 #389 Update accounts page to show 30 accounts in ascending order by creation time. !413 #385 ### 1.11.1-20200213 #### Bug Fixes: Fixed email notification `BEFORE_TRIAL_ENDS` - !408 #382 Log application status changes in the events. - !409 #372 Abandoned accounts (ie accounts that did not complete configurations and app was not started) redirect to complete account configuration page. - !406 #380 Fixed DNS records are not deleted when deleting account - !410 #384 Fixed bug in application Upgrade - !407 #381 ## 1.11.0-20200210 **New Features**: **Blueprint: Shared Components** are now naively supported. This allows creating and managing components that can be shared and accessed by all account components. To add a shared component, in the application manifest (jovianx.yaml) set the directive `deploy_per: application` in the component you would like to be shared. Example shared component: ```yaml - name: mongodb-component version: 1.0.0 provider: helm_chart helm_chart_name: mongodb-chart deploy_per: application # <--------Shared componnet directive helm_set: - key: mongodbUsername value: user - key: mongodbDatabase value: test_db ``` This allows managing the life-cycle of the component separately from individual account components. To manage the life-cycle of shared components, and review shared component status, go to Application > Share Components, this allows to start , stop and upgrade shared components. (!336 #274) ![](/files/-M2yDRyL4b6mLQ69km1l) **Email Notifications Cc and Bcc**: Now you can add Cc and Bcc to all email notifications sent to accounts (!393 #368) ![](/files/-M2yDjNJDdM1BRVhGlXb) **Blueprint Download:** You can now download a blueprint archive from vendor Console !392 #204 ![](/files/-M2yES1yxvgOe0PcIsyA) Email notifications: Report email on errors. It is now possible to receive email notifications when errors occur on account creation. To configure email notifications go to Email Notifications > Send email after application started, on the bottom of the card setup `Report errors to` ( !387 #367) ![](/files/-M2yEkCS3azcaSbSNHFw) **Email Notification Events:** An event is created on sending email notifications !402 #378 **Helm retry Mechanism:** When there helm communication errors occur there's a new retry mechanism that re-tries to execute the command when a re-execution can succeed. !399 #377 #### Bug Fixes: Fixed save PayPal secret details - !389 #361 Fixed endpoints URL on Customer Console !398 #375 Added Limitation of number of vendors !403 #354 ### 1.10.2-20200120 #### Bug Fixes: Resolve UX small labels (!384 #363) ### 1.10.1-200115 #### Bug Fixes: Fix Agree to terms of use and Privacy Policy if configured (!382 #360 ) Fix "Customer Console progress bar design (!381 #359) Fix app dashboard disappears when clicking on "App" top navigation tab"(!380 #358) ## 1.10.0-200112 #### New Features: **Added pagination** for Blueprints, Accounts, Upgrade button (!374 #335 ) **Remove pricing when price is 0**, add billing cycle indication(!375 #347) **UI and UX improvements in customer console hosted sign-up** (!377 #352)(!378 #355)( !379 #356) #### Bug Fixes: Remove unused email var `application url`and fix broken source editor in Email Editor (!369 #327 #329) Fix get Favicon/Custom CSS/CustomJS ( !376 #351) ### 1.9.1-191224 #### Bug Fixes: Fixed endpoints API which returns an error when one/more components don't have endpoints (!373 #342) ## 1.9.0-191224 #### New Features: **Blueprint: Disable endpoints for disabled components:** When a component is disabled, either as a part of component configuration by a \`setting\_descriptor\`, all component's endpoints are disabled too. (!372 #337) ```yaml ... components: - name: component-name enabled: false endpoints: - name: 'User application' service_name: kubernetese-service-name.namespace ... ``` **UX: New Plan form Plans Page**: Create new plan page is now available as a separate page, accessible form the plans list page (!365 #318) ![](/files/-LyjIkxGGqNyf-5KkEf6) **Customer Console Card:** It is now possible to create your own application cards to the customer console. A new endpoint type: card is now available, which shows the content of the entry point URL as a card on the customer console (!337 #278) ```yaml endpoints: - name: 'Application API' service_name: node port: 8008 path: /api type: card # <--------------- dns: '*.jovianx.app' entry_point_url: 'http://{{ account://end_company }}.example.com/app' ``` ![](/files/-LyjPw67xmXfxtfhbTjv) **Email Notifications: endpoint links and labels templates** - You can now reference all your endpoint labels and URLs in the email notification template (!347 #288)
![](/files/-LyjOrZF_IXyYopUU3mR) ```yaml endpoints: - name: my_cool_app service_name: "{{ account://components/my_component/helm_release_name }}-my-k8s-serivce" label: "My cool app" # <-------- port: 9090 path: / type: main_entry_point dns: '{{ account://end_company }}.cloud.example.com' entry_point_url: 'https://{{ account://end_company }}.cloud.gigaspaces.com:' ``` **UX: Embeddable account creation form iFrame does not show footer** links to terms and conditions and and privacy policy (!370 #328) **UX:** New icons on the global dashboard (!368 #326) **UX:** New icons on account application dashboard (!371 #338) #### Bug Fixes: Fixed: Account status icons are not shown (!363 #319) Fixed: Side navigation nested routes are misaligned !364 #322) Fixed: app actions buttons alignment !366 #323) Fixed: Customer Console redirect to application internal authentication is not redirecting into app (!367 #325) ## 1.8.0-191211 **NEW FEATURES**:\ **Blueprint: Immutable settings** - It is now possible to create user defined settings(via `settings_descriptors`) that are immutable. This prevents the end user from being able to change settings that were selected on account creation. (!360 #283) Example: ```yaml settings_descriptors: - name: some_feature display: 'Enable this cool feature' description: 'This option will enable this cool feature' input_type: checkbox # immutable applies to any input type immutable: true # <---------- ``` \ **Blueprint: endpoint labels** - Allows defining labels to endpoints, the labels are presented in the customer console instead of endpoint URL (!342 #287) ```yaml - name: 'Application API' service_name: node port: 8008 path: /api type: entry_point entry_point_url: 'http://{{ account://end_company }}.jovianx.app/app' label: 'This Is My Cool App Endpoint' # <------------------------------------ ``` \ **Email Notification: Added {trial days left} and {trial days total} to all templates** - When creating email templates it is now possible to show the trial time and how many days left in the trial (!346 #280)
**Change trial end date for trial accounts** - You can now change the trial end date for existing trial accounts (!352 #292)
\ **Account application status dashboard shows Kubernetes objects status** (!359 #308) ![](/files/-Lvtc6mNcr7cphWWD8pk) **UX: Email preview variables are unified with variables preview** (!354 #314) ![](/files/-LvtcSfoj8xvT8OGUkPR) **UX: Show confirmation for save action** (!344 #293) {% embed url="" %} \ **UX: Settings in side menu are split into separate pages** (!348 #296 #297)
**UX: Plans in side menu are split into separate pages for plans list and create a new plan page** (!361 #313) ![](/files/-LvteUAuz1vioDwaJKHI) **UI: Login page support for smaller screens** (!356 #311) ![](/files/-Lvu-hWI6a8NqhhHcxfQ) UX: Align title styles and sizes (!355 #312)
**BUGFIXES**:\ Sporadic delays in async and scheduled tasks execution(!349 #303) Agent bootstrap-config link is not created correctly(!353 #305) Font sizes remain same on UI ReactsJS build(!362 #317 #320) Email notification doesn't use correctly environment variable "{ username }" (!350 #304) Application Entry points table is now shown correctly(!357 #309) Remove redundant button "Open Customer Console" from account page (!358 #310) ## 1.7.0-191119 #### New Features: **Blueprint: ability to enable and disable components by settings descriptors** *-* This allows adding and removing helm charts based on used selected settings. For example deploy additional software components when the user selects to enable additional features. (!326 #264) ```yaml ... components: - name: kafka version: 1.0.0 provider: helm_chart helm_chart_name: kafka enabled: false # <-- Kafka is *not* installed by default ... settings_descriptors: - name: select_use_case input_type: select default: select_options: - name: install_kafka display: "Enable Kafka by this selection" components: - name: kafka enabled: true # <-- enable Kafka if users selects option ... ``` **Blueprint: Checkbox with single option action** - This allows defining checkbox in setting descriptors with actions only when enabled, or only when disabled (!330 #217) ```yaml ... settings_descriptors: - name: VPNTunnel display: 'Enable VPN tunnel' description: 'Setup cennection to your app via VPN tunnel' input_type: checkbox default: true select_options: - name: true # <-- helm_set used only when true, no action when false components: - name: node-component helm_set: - key: enable_vpn value: true ... ``` **Blueprint: Design entry\_point\_url when DNS uses wildcards** - When using wildcards in DNS names and Kubernetes Ingress, it is now possible to define the entrypoint URL template for the endpoint. (!331 #276) ```yaml endpoints: - name: 'User application' service_name: ingress.ingress-namespace port: 80 path: /app type: entry_point dns: '*.example.com' # <-- DNS Wildcard entry_point_url: 'https://{{ account://end_company }}.example.com/app' # <-- Optional, If found, use this URL ``` **Blueprint: Disabled radio and Disabled Select** - It is now possible to defined disabled select and radio options in setting descriptors, this is useful for showing features that are not yet available or presenting featured that were deprecated. (!338 #289) ```yaml - name: cloudProvider display: 'Cloud Provider' description: 'You can select amoung three leaders of cloud infrastructure' input_type: radio default: azure description_title: 'Choose your provider' select_options: - name: do enabled: false # <-- Disabled radio option display: 'Digital Ocean' - name: support display: 'Support package' input_type: select default: premium description: 'Basic support is included for all customers and covers availability of the Atlas service, connectivity issues, and questions about the UI or platform features.' select_options: - name: '24/7' display: 'support 24/7' enabled: false # <-- Disabled select option ``` ![Disabled Radio options, Disabled Select Options](/files/-Lu3SMeefoFkbhZrvekf) **Email notification template HTML editor** - It is now possible to edit the HTML of email notification templates. (!340 #272) ![](/files/-Lu3V8lr8nsviQgylWiV) **"Terminate application" option on all app states** - Previously the Terminate Application option was available only when the application was in "running" state, now it is possible to terminate the application on all intermediate states. (!333 #166) ![](/files/-Lu3Z92DEYrMmQcuqGz-) **Customer Console: Application Settings** - users can now view and update their settings from the customer console(!335 #275) ![](/files/-Lu3fISQ46H6BADvM2I_) **Customer Console: Show Agents only when an agent was uploaded** (!329 #277 #279) **Customer Console: Custom HTML page for while app in starting state** - It is now possible to show a custom HTML page while the application is starting and all components and getting ready to be used by the user. (!334 #253) ![](/files/-Lu3io7SnJ427gHGC5oW) **Back button from pod/service/storage views.** (!341 #285) #### Bug Fixes: **Helm connection stream errors** were causes issues fetch app statues, now helm connection errors have special handlers. (!339 #286) **Validate email template variables before saving** - All email notification templates and used account variables { } are now validated upon saving. (!328 #230) **Pods In pending are now show their pending messages** (!327 #266 ) **Prevent negative numbers in the wizard**(!332 #149) **Login screen: enter key triggers login**(!343 #291) ## 1.6.0-191029 #### New Features: **Set email notification FROM field, Set Subject per notification type** - It is now possible to define the reply-to address and the subject line for each of the notification emails sent to end customers. (!215 #260) ![](/files/-Ltsur1y9HtBK56CAdh4) **Delete inactive accounts with grace period and auto delete** - Now it is possible to configure auto-delete period for accounts that are not active(non-paying and out of trial), it is also possible to set the grace period which scales down the application for predefined period before deleting use data. (!281 #177 #178 #179 #132 #254) ![](/files/-LtsuQyWa0Q34w_7WDcr) **Optional Payment on signup** - It is now possible to make payment optional on signup and not require the end user to provide payment details on registration. (!325 #218 #231)
Make payment optional on signup
**Embedded Signup iframe snippets** - You can now just copy/paste our code snippets to embed JovianX signup page within your marketing landing pages. (!317 #267) ![](/files/-LtsvNzeGGxUEvACANUD) #### **Vendor-to-EU Invitation email template editor** - You can now edit the email template that is sent when a user send an invite to a team member. (!307 #243) ![](/files/-Ltt2fdBYpJlrRZ_g3o6) **Application start failures are now logged as events.** (!318 #269) **Updated UI and UX elements for signup and registration wizard.** (!320 #227) **Blueprint: input\_type: select and input\_type: radio now use the the first option as default.** If the default option is not defined or empty the first option is now selected as default. (!323 #270) #### Bug Fixes: Invite members now sends signup URL with HTTPS instead of HTTP(!313 #265) External IPs are now displayed correctly (!324 #248) ## 1.5.0-191020 #### New Features: \#262 **Embeddable Account Signup** - It is now possible to embed JovianX account signup in your own marketing landing pages. ![Embeddable Account Signup](/files/-LrcnR_OsbIwY03YNRJG) \#252 **Select Blueprint Version on account creation** - It is now possible to select the blueprint version for creating a new account on SaaS admin console. #### Bug Fixes: \#265 BUGFIX: invite members now sends invitation links with correct scheme(http/https) \#219 BUGFIX: Favicon in customer Console now refreshes on new ICON upload. \#259 BUGFIX: Application entrypoints UI now supports showing services from other namespaces(Ingress use-case) \#250 BUGFIX: Main dashboard now shows volume sizes correctly \#258 BUGFIX: Account Application page now doesn't show Oops message when app started with blueprint that doesn't have plan. ## 1.4.0-191014 **New Features:** \#210 **Account user management**: Allow JovianX SaaS administrators to invite co-workers into the account. \ Support management of account's users including invitation and removal from an account. ![Customer Account User Management](/files/-Lr9UnahFvvsX3XDNx7c) ![SaaS Admin: Invite co-workers](/files/-Lr9VUzuOSevU0PxEp8a) \#257 **Blacklist email domains:** It is now possible to configure a list of email domain names that are not permitted to sigh-up. This can be used for blocking non-work related email address. ![](/files/-Lr9Q7NWHFzHP8GU1XgQ) \#256 **Application Manifest: Support `service_name` with namespaces as part of `endpoint`configuration.** This can be used for creating DNS A records with an Ingress controller IP address on new account creation. \ Following example is now supported: {% code title="jovianx.yaml" %} ```yaml ... endpoints: - name: 'User application' service_name: node.this-is-a-namespace dns: '{{ account://end_company }}.jovianx.app' ... ``` {% endcode %} \#255 **Application Manifest: First occurrence of `entry_point` acts as default** `main_entry_point` in case `main_entry_point` is not specified. \#209 **Optionally Prevent users from self-signup into existing account.** \#238 **Helm execution outputs are not logged as account events.** This helps to better understand Helm related executions. Bug Fixes: \#249 BUGFIX: Oops error message is shown in some cases when a pod in pending state. \#240 BUGFIX: On account creation screen align custom text field with default text fields. \#246 BUGFIX: Align settings toggles to the right. ## 1.3.0-191001 **New Features:** \#226 **Application URL Template in Email notifications** - Added new template `{Application URL}` that allows using the URL for the application in the email notification that is sent after the application starts. \#228 **Account Signup Custom Fields Order** - It is now possible to change the order of the fields on sign up form.
![Custom Fields Ordering](/files/-LqBJzH7avRJh38SzJYw) \#229 **Log End User Login Events** - When an end-user is logging into the application an event is created in events log. ![Login Events](/files/-LqBL0Ixtd1HGWTkphDg) \#221 **DNS TTL 1 Sec** - DNS records are now created with TTL of 1 second for faster availability. \#214 **Wait Message While App Starts** - For some applications take longer time to start after a user signs up. It is now possible to setup a custom waiting message that is shown on signup.
![Custom Message While App Starts](/files/-LqBLOG4H9bJVeDmAZ09) \#224 **Kubernetes Resources Tabs**: All Kubernetes resources can be found in tabs view for improved visibility of all Kubernetes resources related to an account. ![Kubernetes Resources](/files/-LqBJYoj8MEBzv4Qk4y9) \#222 Show correct protocol http and https for ports 80 and 443 \#223 Kubernetes services now show all available ports exposed by service with links **Bugfixes:** \#212 BUGFIX: Accounts didn't show correctly when some metadata was missing due to missing configuration \#233 BUGFIX: Agent install instructions on account view was not shown \#235 BUGFIX: Manifest: `helm_set` is now optional in application manifest. \#232 BUGFIX: Account creation button was disabled when `agree to terms of use` was not required \#225 BUGFIX: Agree on terms switch is now off by default, making terms of use an opt-in requirement ## 1.2.0-190911 \#191 - Helm release name is now a random 5 chars string to support long account and vendor names \#199 - Blueprint can access the auto generated helm release name via `{{ account://components//helm_release_name }}` \#194 - Admin console | Display application settings and helm parameters in tables \#195 - Support application DNS names in customer console and admin console. \#183 - UX | Enhance data Loader mechanism \#200 - UX | Improved page loader \#198 - BUGFIX - Pricing is calculated incorrectly, PayPal configuration can prevent the application from starting correctly. ## 1.1.0-190908 #### Vendor Console \#175 - End User Reset Password \#103 - Application Manifest Settings Descriptions #### End User Wizard \#192 - End User Signup Wizard Enhancement for drop down menu \#189 - End User Signup Wizard Enhancement - UI \#164 - Admin Console Reset Password \#182 - Button spinners on long operations \#186 - End User Signup Wizard static width \#151 - End User Signup Wizard recalculates price on on-action #### BUGFIXES \#185 BUGFIX - DNS is invoked even when disabled causing applications not on start \#168 BUGFIX - Accounts are not deleted correctly when PayPal is disabled \#190 BUGFIX - Account trial period is not calculated correctly \#100 BUGFIX - Vendor Console account creation now tests password length # Dashboard The main dashboard provides **accounts** overview information for all the managed accounts, and overview of the consumed cloud **infrastructure** resources. ![JovianX Dahsboard](/files/-MGAikKSYnv3zhqrjZRh) ## Accounts The accounts section includes account metrics metrics. **TOTAL** - The total number of accounts managed by JovianX. **ACTIVE** - Accounts with Active subscription. **TRIAL** - accounts that are in Trail period. **SUSPENDED** - Suspended accounts are accounts that did not activate the account after trial period, or account did not renew payment subscription, or accounts that were suspended manually. ## Infrastructure The infrastructure section shows metrics of managed cloud resources. **NODES** - Total number of Kubernetes nodes across all connected clusters. **PODS** - Total number of managed [Pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) across all Namespaces/Clusters. **SERVICES** - Total number of [Kubernetes services](https://kubernetes.io/docs/concepts/services-networking/service/) across all Namespaces/Clusters. **VOLUMES** - Total number of [Kubernetes volumes](https://kubernetes.io/docs/concepts/storage/volumes/) across all Namespaces/Clusters. **STORAGE** - Total amount of storage used by all managed accounts. # Accounts Accounts are the main page for managing your customers. The account object stores the entire Recurly history of your customer and acts as the entry point for working with a customer's billing information, subscription data, transactions, invoices and more. ![Accounts Management ](/files/-M7rS7YQKyiwFzmLahJy) ## Account Status During its existence account can be involved in different event that can change its status. For example end of trial period or problems with payment status. This article describes account statuses that can be seen by users. ![Account statuses transition scheme.](/files/-M8UK0PZWxgOWcaWKNei) ### Statuses descriptions `created` - account was just created and registration process is not finished yet. `trial` - if billing plan defines trial period account will enter in trial period. `active` - account enter in active status in next cases: * billing plan defines no trial and account have disabled payments. * billing plan defined no trial and account should't provide payment method during registration. * billing plan defined no trial and account must provide and provided valid payment method. * trial ended and account have disabled payments. * trial ended and account should't provide payment method during registration. * trial ended and account must provide and provided valid. * account payment subscription returned to active state. `suspended` - account have problems with payments. ### Account Subscription ![](/files/-MGAmjN-bAz-ELik1d0f) ### Change account status ![](/files/-MGAmnSzIGLVups1iQfz) ### Account Users Review account's users. The hosted customer console allows new users to sign up to an account. To allow new users to sign up only via a personal invitation, switch **ON** the option "**Prevent users to signup to this account without invitation**" ![](/files/-MGAmsfqScPT5SEHm95D) ### Account Application ![](/files/-MGAnBlWhg2ghBbDMgMR) ### Account Events the account events tab shows an audit log of all the events occurred to an account. ![](/files/-MGAnXlOTJ21w5nscYqE) # Blueprints ### Introduction An application blueprint is a packaged tarball file (`*.tar.gz`) that contains the application manifest YAML file (`jovianx.yaml`) and the Helm Charts directories that are referenced by the application manifest. The application manifest defines the components used by the application. The components can be Helm Charts or other cloud-managed services. JovianX uses the Application Blueprint to create resources and set up services when a new account signs up. ### Blueprint Structure The application blueprint contains the following: 1. **Application Manifest** - The application manifest is a YAML file named `jovianx.yaml`. The manifest defines the components that are created for a new SaaS account. For example Kubernetes Helm Charts, DynamoDB, CloudDNS or other cloud managed services. 2. **Helm Charts -** The blueprint can also include the Helm Charts that are used for creation of application services. ### Application Manifest(`jovianx.yaml`) The application manifest is a YAML file that describes the application. JovianX uses the manifest to create the needed resources and services when a new account signs-up. A basic template of an application manifest looks as following: {% code title="jovianx.yaml" %} ```yaml # v1 - JovainX API Compatability jovianx_api_version: v1 # string - Name of this SaaS application application_name: '' # semantic versioning - version of this JovianX blueprint version: # string - Name of a component to be used a main application entry point main_endpoint_component: '' # Components section defines all application components and their helm chart implementations components: - name: '' version: provider: helm_chart helm_chart_name: helm_set: # List of key-value pairs to pass to helm on account creation - key: '' value: '' endpoints: - name: '' type: entry_point service_name: '' port: path: '' # Settings Descripts define user inputs and settings_descriptors: # list of descriptos - name: display: '' input_type: string default: '' components: - name: '' # Provide value to this componet helm_set: - key: '' ``` {% endcode %} ### Creating Application Blueprint To create an application blueprint archive the application manifest and helm charts into a blueprint tar.gz ``` $ tar -cf jovianx.yaml ... ``` {% hint style="info" %} Note: The Helm Charts should be open, untar direcotry. {% endhint %} Example: the following directory has an application manifest `jovianx.yaml` and a Chart `my-helm-chart` ```bash ├── my-helm-chart │ ├── charts │ ├── templates │ ├── Chart.yaml │ └── values.yaml └── jovianx.yaml ``` To create an application blueprint for the directory use the following command: ``` $ tar -cf blueprint-1.0.0.tar.gz jovianx.yaml my-helm-chart ``` ### Upload Application Blueprint #### Upload Blueprint via Web UI To upload your application blueprint to JovianX via the web console: 1. Navigate to Blueprints page 2. Click on `Upload a new Blueprint` bar 3. Click on `Choose blueprint tar.gz` file 4. Click on `Upload` to upload your blueprint ![](/files/-Ln7CKts1jDl-2Mh-nb3) Once the blueprint is upload you will be able to find it in the blueprints list, and view the application manifest. #### Upload Blueprint via CURL(CI) To upload your application blueprint to JovianX via an automated CI process or from command line, you will need to find your `API Access Key` and `API Secret`. You can find both in `Upload a new Blueprint` bar under `Blueprints` navigation bar. ``` curl -u ':' -F 'file=@' 'https:///api/v1/upload_blueprint?make_default=true' ``` ## Application Manifest (jovianx.yaml) Reference ## Application Manifest Root | Key | Description | | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `jovianx_api_version` |

Description: Version of the JovianX Manifest API.

Parent: Root
Type: v1

Required

| | `application_name` |

Description: Name of the SaaS Application.

Parent: Root
Type: string

Required

| | `version` |

Description: Version of the JovianX blueprint.

Parent: Root
Type: semantic version

Required

| | `main_endpoint_component` |

Description: Main application end-point.

Parent: Root
Type: string

Required

| | [`components`](/documentation/jovianx-application-blueprint#components) |

Description: components section is a list of all components(Helm Charts or Cloud Managed Services) used as part of the application, and their settings.

Parent: Root
Type: list
Required

| | `application_launch_timeout` |

Description: Application timeout configuration

Parent: Root
Type: collection

Optional

| |

status\_check:
failure\_threshold:

|

Description: How many status error detection are accepted before changing the app status to error.

Parent: Root Type: collection

Default: 1

Optional

| | `agents` |

Description: The list of agents

Parent: Root
Type: list

Optional

| | `settings_descriptors` |

Description: A list of settings descriptors

Parent: Root
Type: list

Optional

| | `hooks` |

Description: List of hooks

Parent: Root
Type: list

Optional

| ## Components Components section is a list of all components used as part of the application, and their settings. Components are Helm Charts or Cloud Managed Services. | Key | Description | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` |

Description: Name of the component

Parent: components
Type: string

Example: name: 'my-component'

Required

| | `version` |

Description: Version of the component

Parent: components
Type: semantic\_version

Example: version: 14.5.2

Required

| | `provider` |

Description: Provider that implements the component

Parent: components
Type: Select
Options:

  • helm\_chart
  • \[Additional providers available in private alpha]

Example: provider: helm\_chart

Required

| | `helm_chart_name` |

Description: Path to unarchived helm chart within the blueprint

Parent: components
Type: string

Example: helm\_chart\_name: /my-helm-chart/

Required for helm\_chart provider

| | `helm_values_file` |

Description: Path to values.yaml file for the component

Parent: components
Type: string

Example: helm\_values\_file: /my-helm-chart/my-values.yaml

Optional for helm\_chart provider

| | `helm_set` |

Description: List of helm set key and value pairs

Parent: components
Type: list

Example:

helm\_set:

- key: image

value: registry.hub.docker.com/my-company/image

Optional for helm\_chart provider

| ## Settings Descriptors | Key | Description | | ------------------- | ---------------------------------------------- | | `name` | **Type**: string | | `display` | **Type**: string | | `input_type` | **value**: string \| number \| radio \| select | | `default` | **Type**: string | | `description_title` | **Type**: string | | `select_options` | **Type**: list | ## Hooks | Key | Description | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pre_install` |

Description: List hooks that are executed before app install

Parent: hooks
Type: list

Optional

| | `post_install` |

Description: List of hooks that are executed after app install

Parent: hooks
Type: list

Optional

| ### Hook | Key | Description | | ----------- | ----------- | | name | | | on\_failure | | | timeout | | | provider | | | image | | | command | | | args | | | env | | ## Variables ### Account ``` {{ account://vendor_company }} ``` ``` {{ account://end_company }} ``` ``` {{ account://account_api_key }} ``` ``` {{ account://admin_email }} ``` ``` {{ account://admin_password }} ``` ``` {{ account://api_host }} ``` ``` {{ account://application_version}} ``` {% code title="example" %} ``` components: - name: node-component version: 1.0.0 provider: helm_chart # helm_chart | docker helm_chart_name: node-chart helm_values_file: values-jovianx.yaml helm_set: - key: repository value: https://gitlab.com/jovianx-saas-platform/hello-world-app.git - key: replicas value: 1 - key: vendor_company value: '{{ account://vendor_company }}' - key: end_company value: '{{ account://end_company }}' - key: account_api_key value: '{{ account://account_api_key }}' - key: admin_email value: '{{ account://admin_email }}' - key: admin_password value: '{{ account://admin_password }}' - key: api_host value: '{{ account://api_host }}' ``` {% endcode %} ### Application # Plans ![](/files/-MGAthJvTMXe5hf_pb3f) ![](/files/-MGAtnbEXjwOt7-6cAcU) # Settings ### Docker Private Registry Docker images of the application can be stored on a private docker registry, you can setup and configure JovianX to use a private docker registry. This created a ![Docker Private Registry](/files/-LrDTP2Y7UXdx8NWbkIO) To enable Docker Private Registry 1. Go to **Settings** > **Application** > **Docker Private Registry** 2. Toggle Docker Private Registry **ON** (upper right corner of the card) 3. Configure your account details: 1. Registry URL 2. Registry Username 3. Registry Password 4. Your email address ### Manage DNS Records JovianX can create and manage DNS records for new customer accounts. When a new account is created {% hint style="info" %} **Note:** DNS Name is not the time now {% endhint %} # Infrastructure ## Application Infrastructure ### Kubernetes configurations ### Docker Private Registry ### Manage DNS Records ## Cloud Provider Managed Kubernetes Services ### Azure Kubernetes Service Configurations #### Configurations ![](/files/-MGDVA5D9u33uGc_cKAz) #### New AKS Cluster ![](/files/-MGDVavzRjPNihemA5br) ![](/files/-MGDVoNLmYpXUW2hASB0) # Customer Console # Emails Blacklist **Emails Blacklist** allows setting email address patterns that are not allowed to sign-up to the service. This is useful in cases you would like to prevent certain email address or domain names from registration to the service. ![Emails Blacklist blocks hotmail.com gmail.com and .edu domain names](/files/-Lr3YIRH-HRywqsrd3lW) ### How to add a new Blacklist rule 1. Click `Add Rule` to add a new rule 2. In the text-box enter a pattern. (For example `blacklisteddomain.com`) 3. Click on `Save Blacklist` to save changes # Email Notifications # Automation Automation allows creating automation rules, that trigger actions based on JovianX events. Once a rule is triggered it calls an action webhook, that can send information from JovianX to external cloud services. **Automation** effectively allows integration with external services such as [HubSpot](https://hubspot.com), [Slack](https://slack.com), [Jira](https://www.atlassian.com/software/jira), [Freshdesk](https://freshdesk.com/), [Pager Duty](https://pagerduty.com/) and others. ![](/files/-M51upCQXOztDq-zvHDW) ### Events‌ JovianX allows configuring automation rules for the following events: * Customer account created * Customer account deleted * Customer account trial is over * Customer account user created * Customer account user logged in * Application helm parameters changed * Application launch settings changed * Application upgraded * Application error * Email notification sent ### Actions JovianX supports the following action Types: {% tabs %} {% tab title="Webhook" %} ### Webhook JovianX calls a webhook when an automation rule is triggered. ‌To configure a Webhook set the following settings: #### URL The URL of the Webhook Must be a valid web address URI. #### ‌Method You can define the URL method for JovianX to trigger, following methods are supported: * GET * POST * PUT * PATCH #### **Headers** Custom headers are supported, you can define a custom `key: value` pairs of headers. Additionally, you can use **variables** as header `values`: ![](/files/-M52302G5MpGk6aa7uRW) **Content:** The content section holds the Webhook request content data, you can define the content type and configure the data to send. **Content Type** * JSON * MULTIPART/FORM-DATA * X-WWW-FORM-URLENCODED **JSON** content-type allows defining the JSON content data: ![](/files/-M52AjgWSpuL21Ky9Ye1) **MULTIPART/FORM-DATA** and **X-WWW-FORM-URLENCODED** allow setting the `key:value` data: ![](/files/-M52B31pSxB1IUn8dBak) {% endtab %} {% endtabs %} ### Available Variables Events expose a set of **variables** that can be used as event data or headers when triggering an action: | Event | Supported Variables | | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Customer account created

Event triggered on successful customer account creation.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

| |

Customer account deleted

Event triggered on deletion of customer account.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

| |

Customer account trial is over

Event triggered when customer account trial period is over.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

| |

Customer account user created

Event triggered on creation of new account user

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

{{user\_email}}: User email address

{{user\_name}}: User full name

| |

Customer account user logged in

Event triggered when account user logs into the customer console.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

{{user\_email}}: User email address

{{user\_name}}: User full name

| |

Application helm parameters changed

Event triggered on update of application ' 'components helm parameters.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

{{parameters}}: Application components helm parameters after successful update

| |

Application launch settings changed

Event triggered when account settings are changed.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

{{parameters}}: Application components helm parameters after successful update

{{application\_settings}}: New application settings chosen by user.

| |

Application upgraded

Event triggered after successful application blueprint ' 'version change.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

{{parameters}}: Application components helm parameters after successful upgrade.

{{old\_blueprint\_version}}: Application blueprint version before upgrade

{{new\_blueprint\_version}}: Application blueprint version after upgrade

| |

Application error

Event triggered when application state changes to "error".

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

{{previous\_state}}: Application state before it was changed to "error"

{{parameters}}: Application components helm parameters

{{application\_settings}}: Application settings chosen by user

| |

Email notification sent

Event triggered after an email notification is sent.

|

{{account\_id}}: Account identifier

{{account\_display\_name}}: Account company name provided during registration

{{receiver}}: To whom notification was sent

{{subject}}: Subject of the email notification

{{message}}: Body of the email notification

| ### Creating a new automation Rule To create a new automation rule : 1. Navigate to `Settings` > `Automation` on the side-menu. 2. Click on Create rule button on the upper left side ![](/files/-M51uyyrMT3UXRFx5Dzd) #### Example JovianX > Slack integration: ![](/files/-M51vkKOSP7DCCn0caOd) # Payments # Members # Integrations JovianX supports integration with leading cloud services. #### HubSpot #### Slack #### FreshDesk #### PagerDuty #### SquadCast #### Stripe #### PayPal #### Azure #### Google Cloud Platform #### Amazon Web Services #### Kubernetes #### Helm # PagerDuty + JovianX Integration JovianX supports integration with PagerDuty, to automatically create and triggers production incidents within PagerDuty, and automatically mark resolved incidents when they are resolved. ## Benefits * Notify on-call respondents when the application status of an account turns to `Error` state. * Automatically mark issues as Resolved when application's status switches from Error to Running. * One-way event notification forwards from JovianX to PagerDuty. ## How it works JovianX Automation feature allows triggering external cloud services on events happening within JovianX, and data from JovianX to the service. This integration uses the `Application Error` event, which triggers the PagerDuty Events V2 API, to create an incident within PagerDuty. ## Requirements * PagerDuty integrations require an Admin base role for account authorization. If you do not have this role, contact an Admin or Account Owner within your organization to configure the integration. * PagerDuty <> JovianX integration requires an **`integration key`**, and alerts and incidents must be enabled. Integration keys are generated by creating a [new service](https://dev-jovianx.pagerduty.com/services/new) or by creating a new integration for an existing service. ## Support If you need help with this integration, contact or open a ticket with the customer support portal. ## Integration Walkthought Follow steps below to setup the integration between JovianX and PagerDuty. ## In PagerDuty #### Integrating With a PagerDuty Service 1. On the top menu, click on **Configuration** > **Services**. 2. Add an I**ntegration** to a service through **ONE** of the following methods: 1. Add integration to **existing service** - Click the name of the service where you want to add the integration. Then select the Integrations tab and click **New Integration,** and copy the **Integration Key**. The Integration Key will be used to connect JovianX Platform to the PagerDuty account.
2. **Create new Service** - Click on "+ New Service" button, set the name of the new service to "JovianX Platfrom", then select **Integration Type**: **Use our API directly** with **Events API v2,** configure the rest of the Pagerduty settings, and click on "**Add Service**" button at the bottom of the screen. On the next screen navigate to the **Integrations** tab, and copy the **Integration Key**. The Integration Key will be used to connect JovianX Platform to the PagerDuty account. ![Copy the PagerDuty Integration Key](/files/-M8paK2y4Te4DJ19akwL) {% embed url="" %} PagerDuty Service Creation for JovianX Integration {% endembed %} ## In JovianX Platform #### Create New JovianX Event Automation Rule Create a new Rule 1\. On the left menu click on `Automation` and then click on `Create Rule` ![](/files/-M8fV2o5519JS7fXdVV_) 2\. Create a new rule with the following configuration: * [ ] Choose the event type: `Application Error` * [ ] Application Type: `Webhook` * [ ] URL: `https://events.pagerduty.com/v2/enqueue` * [ ] Content Type: `JSON` with the following content: ```javascript { "event_action": "trigger", "payload": { "summary": "Account {{account_display_name}} changed to ERROR state.", "source": "JovianX Platform", "severity": "error" }, "routing_key": "" } ``` 3\. To test the configuration click on **Test** ![](/files/-MGmdBb7_vDx5tulLkns) A successful call to PagerDuty should result in a similar response. On the PagerDuty console a new incident should be created.
![](/files/-MCIOyV7NEiMEIednYT2) ![](/files/-MGmdR46O5NPXqkczV3P) 4\. Click on **Save** if the test result was successful. {% hint style="info" %} Note: You can read further about PagerDuty API on the PagerDuty API documentation. {% endhint %} # Adding Clusters to JovianX JovianX supports management of multiple Kubernentes clusters, allowing to run and manage workloads on multiple cloud providers in multiple regions simultaneously. ![Kubernetes Multi-Cluster Management](/files/-M4imjRZT_RfU1uM-YZK) ## Kubeconfig Kubernetes Cluster Access File Kubernetes uses a YAML file called [`kubeconfig`](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) to store cluster authentication information. JovianX uses `kubeconfig` files to access the Kubernetes clusters. The `kubeconfig` file contains a list of contexts to which JovianX can refer when running Kubernetes operations. ### Step 1 - Prepare an administrative Kubeconfig file Create a new `kubeconfig` file, which will be used for controlling the Kubernetes cluster. The `kubecofnig` files should include configuration for `context`, which should define a `cluster` and a`user` . User is a Kubernetes service account that has the **cluster-admin** role. #### Example Kubeconfig file {% code title="$ cat kubeconfig-example.yaml" %} ```yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: server: https:// name: contexts: - context: cluster: user: name: kind: Config preferences: {} users: - name: user: token: ``` {% endcode %} {% hint style="info" %} Read more about Kubeconfig in the official[ Kubernetes documentation.](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) {% endhint %} {% hint style="success" %} You can **generate an administrative Kubeconfig** file using the Generate-Kubeconfig script . `$ ./kubeconfig-create.sh`\ `Generate administrative Kubeconfig file for your cluster` `This script generates a Kubeconfig file that allows full administrative access to your cluster Please note that this creates a Kubernetes service account 'jovianx-admin' with`` `*`CLUSTER-ADMIN`*` ``role in the 'jovianx-system' namespace.` `Proceed?[Y/n]`\ `...` {% endhint %} ### Step 2 - Upload Kubeconfig files JovianX uses Kubeconfig files to interact with a Kubernetes cluster. To upload a Kubeconfig file: 1. navigate to `Settings` > `General` > `Application` 2. Open `Kubernetes configuratio` 3. Click on **Select Kubeconfig file** Once you upload a Kubeconfig file, all cluster details are visible in the main dashboard.
{% hint style="info" %} **Note**: The Kubeconfig file should specify a service account with **cluster-admin** role, and should include an authentication **token,** as show in [example above.](/guides/kubernetes-multi-cluster-management#example-kubeconfig-file) {% endhint %} {% hint style="danger" %} JovianX allows uploading multiple Kubeconfig files, and supports one context per file. {% endhint %} ### ### Step 3 - Add Kubernetes Context to the blueprint JovianX allows defining what context to use for each component, thus, to define where to deploy component's Helm Chart. The definition can be set in the `components` section, making it a static definition. Or by setting the context by `settings_descriptors`, which allows the user to provide input(option selection) that results in setting context for a component. You can add context in the `component` directly, or set it by `settings_descriptors`. #### **Set the context by `component`:** To set the context in the components section, making it a static setting, add the `kube_context` directive: ```yaml - name: node-component version: 1.0.0 provider: helm_chart helm_chart_name: node-chart kube_context: # <--------------------- ... ``` #### Set the context by `settings_descriptors`: To set context by a user input for a setting descriptor, add the `kube_context` directive in the `components` section: ```yaml - name: choose_cloud_region display: 'Choose cloud provider region' input_type: radio default: 'us-west-1' select_options: - name: 'us-west-1' display: 'US West (N. California)' components: - name: node-component kube_context: # <----------- ... - name: 'us-east-1' display: 'US East (N. Virginia) ' components: - name: node-component kube_context: # <----------- ... ``` `kube_context` is a supported directive for settings\_descriptors of the following descriptor types: radio, select and checkbox # New Cluster Considerations JovianX supports adding your own Kubernetes clusters. When creating a new cluster to be used with JovianX Platform, there are few considerations that should be taken into account. ### Cluster Naming The cluster name should include the following: 1. Include "**jovianx**" and **your company name** as part of the cluster name. 2. Include the name of the **cloud provider** (ie aws/gcp/azure). 3. Include the **region/zone** name. 4. Include your own **cluster id**, this can be a string describing the specific purpose of the cluster(ie staging, trials, sandbox) or cluster count index(useful when utilizing multiple clusters per region). A good example for cluster name would be `jovianx-acme-aws-us-east-2-prod`. ### Cloud Provider, Cluster Location and Type (Zonal/Regional) Consider carefully the cloud provider, and the region/zone where the cluster is located. **End-users prefer to utilize services that are co-located with their other resources**. For example if your users run their infrastructure services on AWS US-East, they would prefer to co-locate your cloud service in the same region or zone and on the same cloud provider. You can also make your service available in multiple cloud providers and regions, and allow the users to choose their cloud provider and region. In GKE, when creating a new cluster the cluster's master node runs in a **single zone**. You can define a new GKE cluster as **Regional cluster**. Defining a new cluster as regional cluster increases it's availability, so if one zone become unavailable, or the cluster undergoes upgrades, the cluster's control plane remains accessible. GCP doesn't charge an extra fee for regional management, but requires having worker nodes in each zone. Read more about GCP Regional Cluster [HERE](https://cloud.google.com/kubernetes-engine/docs/concepts/regional-clusters). ### Cluster Sizing Kubernetes manages multiple nodes in a single cluster. The cloud providers allows adding **groups of nodes** of the **same instance type**. In AWS EKS these groups are called "Node Groups", GCP GKE and Azure AKS calls them "Node Pools". ![](/files/-M7WsGC6NN4D3YO97GLL) The cloud provider allows **scaling** the node groups in and out. The scale-in and scale-out can be done **manually**, or **automatically.** Automatic sacle in and scale out is done based on the load of the nodes. The automatic scaling of node groups policy relays on [**Metrics-Server**](https://github.com/kubernetes-sigs/metrics-server) to be deployed in the cluster. Metrics-Server is deployed by default in GKE, but required to be manually added to EKS. JovianX runs each account's resources(`Pods`, `Persistent Volumes`, `Services`, etc') in a separate `Namespace`. Pods of the application are scheduled and placed by the Kubernetes scheduler. When planning the size of a cluster, there are a few considerations to take into account, and how to place the application workload components. #### Single Node Group, Node Per Application You can size the cluster such that it has a singe node group, each node fits to run all the components of the application. When new accounts register, the node auto-scaler adds an additional node to the cluster, and the Kubernetes Scheduler places the components of the new account into the newly added node. This is effective to guarantee resources for each account, but may lead to underutilized instances of inactive or underutilized accounts. ![](/files/-M7WsxQIhBqiDNFfl_3z) #### Single Node Group, Large Nodes Another approach could be to create a single node group of large instances, each instance can run resources of multiple accounts, and scale when the resources of a node are exhausted. ![](/files/-M7WtWv4BqQRYoCIlgqB) #### Node Group Per Component Also, it is possible to create a node group per component, matching the size of instances of each node group to the needed resources for the component. ![](/files/-M7WwRIWB0ZkMDCM68T5) {% hint style="info" %} **Note:** JovianX runs each account's resources in a separate Namespace. It is possible to define the placement of accounts's resources in a specific node-pool by using `nodeSelector` label. {% endhint %} ### Node Pool/Group Naming When creating node-pools, it is advisable to set a meaningful naming for the node group, and keep a consistent naming scheme across cloud providers and regions. The cloud providers automatically add the cluster name to the name of the nodes,`kubectl`command-line tool truncates the name of objects to 64 chars, make sure to have the unique node pool identification at the beginning of the pool name. ### Workload Placement The Kubernentes [scheduler](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/) sets the placement of pods based on filters and scores. It is define workload placement by setting by several methods. #### [NodeSelector](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) The `nodeSelector` Kubernetes directive allows defining key-value pairs, as part of the pod spec, and schedules the pod only on node with matching labels. It is possible to use manually set node labels, or use the auto generated node-pool labels. {% code title="jovianx.yaml" %} ```yaml - name: node-component helm_set: - key: nodeSelector value: "eks.amazonaws.com/nodegroup=nodepool-system" ``` {% endcode %} #### [Node Taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) `nodeTaints` repel pods with set of matching key=value pairs. Read [HERE](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) on configuration and setting nodes with node taints. ```bash kubectl taint nodes node1 key=value:NoSchedule ``` ### Preemptive/Spot Node Instances The cloud providers offer Preemptive or Spot instances, which are significantly cheaper than the standard on-demand instances. Preemtive/Spot instances are shorted lived VMs that can be used as nodes for Node groups. These instances are constantly rebooted by the cloud provider. ### The JovianX System Node-Pool JovianX runs various components as part of the cluster in order to collect container logs, monitor the cluster, and allow inbound traffic. These components are deployed in the `jovianx-system` namespace. It is recommended to create a dedicated Node-pool for the JovianX-system components as they may be resource intensive, and it is advisable for these components not to influence end-user workload performance or availability. ### Storage Class Each cloud provider has it's own default naming for the default storage class. If you are using clusters in multiple cloud providers, make sure that each all clusters have matching names for storage classes, so when the scheduled on any clsuter would be able to use the correct storage class. {% tabs %} {% tab title="GKE SSD" %} {% code title="gke-ssd-storageClass.yaml" %} ```yaml kind: StorageClass metadata: name: pd-ssd parameters: type: pd-ssd provisioner: kubernetes.io/gce-pd reclaimPolicy: Delete volumeBindingMode: Immediate ``` {% endcode %} {% endtab %} {% endtabs %} ### [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints. NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods. {% hint style="info" %} Note: Since JovianX uses namespaces to segereate between cusotmer workloads, it is a good practice to prevent netowrk traffic between namespaces. [Here](https://gardener.cloud/050-tutorials/content/howto/network-isolation/) is an example configuration. {% endhint %} ### Cloud Resources Quotas To avoid running into cloud provider quota issues, when creating a cluster with many nodes, conside Increasing the quota for things like CPU, IPs, etc. {% tabs %} {% tab title="GCP" %} In GKE, define the needed quota for: * CPUs * VM instances * Total persistent disk reserved * In-use IP addresses * Firewall Rules * Forwarding rules * Routes * Target pools GCP Quota documentation can be found here: [LINK](https://cloud.google.com/compute/quotas) {% endtab %} {% endtabs %} ### Container Sandbox(gVisor) Sandbox provides an extra layer of security to prevent code from affecting the host kernel on your cluster nodes. Enabling or disabling container sand-boxing may impact applications performance. Read more [here](https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods) for GKE Container Sandbox. # Creating AWS ELK Cluster ### 1. Installing eksctl commandline tool `elsctl` is a popular command-line tool to create and manage Elastic Kubernetes Service (EKS) on AWS. To install elsctl run following commands: ```bash # Download the latest version of eksctl commandline tool $ curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp # Move eksctl to your default command path $ sudo mv /tmp/eksctl /usr/local/bin ``` {% hint style="info" %} You can add`eksctl` to the bash completion by running: `$ cat '. <(eksctl completion bash)' >> ~/.bashrc` {% endhint %} ### 2. Set AWS account credentials Configure your aws credentials files `~/.aws/credentials`. It should define the `aws_access_key_id` and `aws_secret_access_key`: ```scheme [default] aws_access_key_id=A*****s aws_secret_access_key=tm******f ``` You can also configure the default output and region in file `~/.aws/config` ```bash [default] region=us-east-2 output=yaml ``` More details on aws command-line tool configuration can be found [HERE](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html). ### 3. Create a new EKS Cluster ```bash # Create a new Kubernetes cluster using eksctl command $ eksctl create cluster --name jovianx--us-east-2 \ --region us-east-2 \ --version 1.15 \ --managed \ --nodegroup-name jovianx-system \ --node-type t3.large \ --nodes 2 \ --nodes-min 2 \ --nodes-max 20 \ --asg-access \ --external-dns-access \ --full-ecr-access \ --alb-ingress-access \ --auto-kubeconfig ``` # Creating Azure AKS Cluster #### Create an Azure service principal with the Azure CLI {% embed url="" %} Or #### Use the portal to create an Azure AD application and service principal {% embed url="" %} # Kubernetes Cluster System Components ## Overview JovianX manages Kubernetes clusters Container Logging | Elastic + FluentD Monitoring | Prometheus + Grafana Cluster Access Gateway | Ambassador + Cert-Manager ## Installing Ambassador Gateway ```bash # Create the jovianX-system namespace $ kubectl create namespace jovianx-system # Add Ambassador Helm Repo $ helm repo add datawire https://www.getambassador.io # Install Ambassador in the JovianX-System namespace $ helm install --name ambassador --namespace jovianx-system datawire/ambassador --set nodeSelector\\.eks\\.amazonaws\\.com/nodegroup=gigaspaces-nodepool-system ``` {% hint style="info" %} Note: Configure nodeSelector to run Ambassador on the jovianx-system node pool. Note that node selector has To view current labels on the nodes run `$ kubectl get nodes --show-labels` . then {% endhint %} Note that nodeSelector has to escape dot(`.` )char.