SYSTEM AND METHOD FOR DEPLOYING A CONTAINERIZED PRODUCT WITHOUT AN ORCHESTRATOR
In aspect, a computerized method for deploying a containerized product without an orchestrator comprising: providing a single service builder and a single deployer pipeline that is used across for a plurality of services; implementing an automation flow, wherein each service of the plurality of services comprises a plurality of configuration keys and wherein the automation flow dynamically populates and injects plurality of configuration keys into a container during a deployment operation; and implementing an automation of the automation flow.
1 . A computerized method for deploying a containerized product without an orchestrator comprising:
providing a single service builder and a single deployer pipeline that is used across for a plurality of services;
implementing an automation flow, wherein each service of the plurality of services comprises a plurality of configuration keys and wherein the automation flow dynamically populates and injects plurality of configuration keys into a container during a deployment operation; and
implementing an automation of the automation flow.
2 . The method of claim 1 , wherein the step of implementing the automation flow further comprising:
maintaining a template.conf in every applicable repo root.
3 . The method of claim 2 , wherein the template.conf in every applicable repo root comprises a skeleton of an applicable service configuration file.
4 . The method of claim 3 , wherein the template.conf is base64 encoded and added as a label to a docker image being built.
5 . The method of claim 1 , wherein the automation flow populates applicable service configuration file by:
learning one or more values that are specific to each deployment containerized product environment.
6 . The method of claim 3 , wherein the automation flow populates applicable service configuration file by:
using key vault; and
attributing for a cost of retrieval and rate limiting at the key vault side depending on how many retrievals can happen during major release to multiple environments.
7 . The method of claim 5 , wherein the service builder takes six (6) parameters.
8 . The method of claim 6 , wherein the six parameters comprises a Repo Name, a Commit Identifier, a Cluster Type, a Branch Name, a Deployment, and a Script Name.
9 . The method of claim 7 , wherein every service docker image is named after the repo.
10 . The method of claim 9 , wherein the step of implementing the automation of the automation flow such that each release deployment is performed by following the release notes, which is an extensive document that contains all the service names that can have to be built and deployed, and then the unique set of scripts for each service, and the policies that can have to be loaded.
11 . The method of claim 10 further comprising:
utilizing the single service builder and a single deployer pipeline to parses the release notes and builds a plurality of service images to a container registry; and
utilizing the single service builder and a single deployer pipeline to handle a deployment of all the plurality of services.
12 . The method of claim 11 , wherein the single service builder:
provides a Service Repo Clone and Checkout to an applicable branch
encodes a template.conf to add as a label to a Docker image of each service;
clones each dependent repo; and
provides a docker image build and push to the container registry.
13 . The method of claim 12 wherein the single service deployer four (4) parameters comprising a Service Name, Tag number of a docker image tag that is to be deployed), a Cluster Type and a Script Name.
14 . The method of claim 13 , further comprising:
implementing a service builder pipeline.
15 . The method of claim 14 , further comprising:
taking a service name and then a clone the repo.
16 . The method of claim 15 , further comprising:
for a core user interface (UI), implementing an angular build that is configured to be implemented separately.