From c0a31af19edff926836920ee53a4955d0d297053 Mon Sep 17 00:00:00 2001 From: junaid18183 Date: Tue, 9 Jul 2024 12:53:40 +0000 Subject: [PATCH] deploy: 8d0bf3c528442dc59fe364dbcafcc3c56da93155 --- docs/getting-started/helm-values/index.html | 2 +- search-index.json | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/getting-started/helm-values/index.html b/docs/getting-started/helm-values/index.html index ca80eca..dea251c 100644 --- a/docs/getting-started/helm-values/index.html +++ b/docs/getting-started/helm-values/index.html @@ -12,4 +12,4 @@ How-to Guides

    • Helm Values

    ENBUILD Helm Chart Values

    The following key value pairs are used to configure ENBUILD.

    Parameters

    Global parameters

    NameDescriptionValue
    global.AppVersion[default: “”] Provide custom appVersion, to override the default one. All the ENBUILD images will be of the same version. To use indidual tag for each service set the tag on per service basis.""
    global.domainWhat domain to use to expose the ENBUILD using istio or Ingressijuned.com
    global.disable_tls_gitlabSet to true if you are using self-signed certificatesfalse
    global.ingress.enabledShould we create the Ingress Resources ?false
    global.ingress.tlsIs Ingress TLS enabled ?false
    global.ingress.tls_secretIf Ingress is TLS enabled, Provide the Secret for the TLS Certificate.""
    global.ingress.classnameIngress classname if enabled.""
    global.ingress.annotationsIngress annotations if enabled.[]
    global.istio.enabledShould we create the Istio Resources ?false
    global.istio.gatewayIstio gateway to use for creating Virtual Service.istio-system/main
    global.image.registryContainer registry to pull images fromregistry.gitlab.com
    global.image.pullPolicyContainer imagePullPolicyAlways
    global.image.registry_credentialsif the image.registry is private container registry, provide the credentials{}
    global.image.registry_credentials.usernameContainer registry Username""
    global.image.registry_credentials.passwordContainer registry password""

    Jupyterhub Parameters

    NameDescriptionValue
    jupyterhub.cull.enabledDeploy Jupyterhubfalse

    ENBUILD RabbitMQ parameters

    NameDescriptionValue
    rabbitmq.enabledSet to false to use existing RabbitMQtrue
    rabbitmq.replicaCountRabbitMQ replicaCount1
    rabbitmq.auth.usernameRabbitMQ usernameadmin
    rabbitmq.auth.passwordRabbitMQ passwordSuperSecret
    rabbitmq.auth.erlangCookieRabbitMQ erlangCookielamba
    rabbitmq.hostIf rabbitmq.enabled is false , provide the right rabbitmq endpoint""
    rabbitmq.queue_prefixQueue Prefix for all RabbitMQ Queuesenbuild

    ENBUILD Backend/DB parameters

    NameDescriptionValue
    mongodb.enabledSet to true to Deploy the MongoDB.false
    mongodb.mongo_root_usernameDB username. If mongodb.enabled this is used to to set the username. Else this is username for existing Cosmos or DocumentDB""
    mongodb.mongo_root_passwordDB Password. If mongodb.enabled this is used to to set the password. Else this is password for existing Cosmos or DocumentDB""
    mongodb.mongo_serverIf mongodb.enabled is false , provide the right cosmosDB/DocumentDB endpoint""
    mongodb.image.repositoryContainer repository for mongodb Containerenbuild-staging/vivsoft-platform-ui/mongodb
    mongodb.image.tagContainer tag for mongodb Container4.4.5

    ENBUILD UI Services parameters

    NameDescriptionValue
    enbuildUi.image.repositoryContainer repository for enbuildUienbuild-staging/vivsoft-platform-ui/enbuild-frontend
    enbuildUi.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildUi.replicasContainer enbuildUI Replicas1
    enbuildUi.service_typeenbuildUI service_typeClusterIP
    enbuildUi.node_portenbuildUI node_port30080
    enbuildUi.hostnameenbuild service hostname. enbuildUi.hostname.global.domain becomes your FQDNenbuild
    enbuildUi.kiali_urlkiali_urlhttps://kiali.ijuned.com/kiali/
    enbuildUi.grafana_urlgrafana_urlhttps://grafana.ijuned.com/
    enbuildUi.loki_urlloki_urlhttps://grafana.ijuned.com/d/liz0yRCZz/logs-app?orgId=1
    enbuildUi.kubecost_urlkubecost_urlhttps://kubecost.ijuned.com/overview.html

    ENBUILD Backend Services parameters

    NameDescriptionValue
    enbuildBk.image.repositoryContainer repository for enbuildBkenbuild-staging/vivsoft-platform-ui/enbuild-backend
    enbuildBk.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildBk.replicasContainer enbuildBk Replicas1
    enbuildBk.service_typeenbuildBk service_typeClusterIP
    enbuildBk.encryption_keyencryption_key to be used by Backendencryption_key

    ENBUILD USER Services parameters

    NameDescriptionValue
    enbuildUser.image.repositoryContainer repository for enbuildUserenbuild-staging/vivsoft-platform-ui/enbuild-user
    enbuildUser.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildUser.replicasContainer enbuildUser Replicas1
    enbuildUser.service_typeenbuildUser service_typeClusterIP

    ENBUILD Sync Services parameters

    NameDescriptionValue
    enbuildSync.image.repositoryContainer repository for enbuildSyncenbuild-staging/vivsoft-platform-ui/enbuild-cronjob
    enbuildSync.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildSync.replicasContainer enbuildSync Replicas1

    ENBUILD ML Services parameters

    NameDescriptionValue
    enbuildMl.enabledShould we create the ENBUILD ML microservice ?false
    enbuildMl.image.repositoryContainer repository for enbuildMlenbuild-staging/vivsoft-platform-ui/enbuild-ml
    enbuildMl.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildMl.replicasContainer enbuildMl Replicas1
    enbuildMl.service_typeenbuildMl service_typeClusterIP

    ENBUILD GenAI Services parameters

    NameDescriptionValue
    enbuildGenAI.enabledShould we create the ENBUILD GenAI microservice ?false
    enbuildGenAI.image.repositoryContainer repository for enbuildGenAIenbuild-staging/vivsoft-platform-ui/enbuild-genai
    enbuildGenAI.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildGenAI.replicasContainer enbuildGenAI Replicas1
    enbuildGenAI.service_typeenbuildGenAI service_typeClusterIP
    enbuildGenAI.api_keyapi_key for OpenAI service.dummy

    ENBUILD Request Services parameters

    NameDescriptionValue
    enbuildRequest.enabledShould we create the ENBUILD Request microservice ?false
    enbuildRequest.image.repositoryContainer repository for enbuildRequestenbuild-staging/vivsoft-platform-ui/enbuild-request
    enbuildRequest.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildRequest.replicasContainer enbuildRequest Replicas1
    enbuildRequest.service_typeenbuildRequest service_typeClusterIP
    Prev
    ENBUILD UI walkthrough
    Next
    ENBUILD Repositories
    \ No newline at end of file +References

    Helm Values

    ENBUILD Helm Chart Values

    The following key value pairs are used to configure ENBUILD.

    Parameters

    Global parameters

    NameDescriptionValue
    global.AppVersion[default: “”] Provide custom appVersion, to override the default one. All the ENBUILD images will be of the same version. To use indidual tag for each service set the tag on per service basis.""
    global.domainWhat domain to use to expose the ENBUILD using istio or Ingressijuned.com
    global.disable_tls_gitlabSet to true if you are using self-signed certificatesfalse
    global.ingress.enabledShould we create the Ingress Resources ?false
    global.ingress.tlsIs Ingress TLS enabled ?false
    global.ingress.tls_secretIf Ingress is TLS enabled, Provide the Secret for the TLS Certificate.""
    global.ingress.classnameIngress classname if enabled.""
    global.ingress.annotationsIngress annotations if enabled.[]
    global.istio.enabledShould we create the Istio Resources ?false
    global.istio.gatewayIstio gateway to use for creating Virtual Service.istio-system/main
    global.image.registryContainer registry to pull images fromregistry.gitlab.com
    global.image.pullPolicyContainer imagePullPolicyAlways
    global.image.registry_credentialsif the image.registry is private container registry, provide the credentials{}
    global.image.registry_credentials.usernameContainer registry Username""
    global.image.registry_credentials.passwordContainer registry password""

    Jupyterhub Parameters

    ENBUILD RabbitMQ parameters

    NameDescriptionValue
    rabbitmq.enabledSet to false to use existing RabbitMQtrue
    rabbitmq.replicaCountRabbitMQ replicaCount1
    rabbitmq.auth.usernameRabbitMQ usernameadmin
    rabbitmq.auth.passwordRabbitMQ passwordSuperSecret
    rabbitmq.auth.erlangCookieRabbitMQ erlangCookielamba
    rabbitmq.hostIf rabbitmq.enabled is false , provide the right rabbitmq endpoint""
    rabbitmq.queue_prefixQueue Prefix for all RabbitMQ Queuesenbuild

    ENBUILD Backend/DB parameters

    NameDescriptionValue
    mongodb.enabledSet to true to Deploy the MongoDB.false
    mongodb.mongo_root_usernameDB username. If mongodb.enabled this is used to to set the username. Else this is username for existing Cosmos or DocumentDB""
    mongodb.mongo_root_passwordDB Password. If mongodb.enabled this is used to to set the password. Else this is password for existing Cosmos or DocumentDB""
    mongodb.mongo_serverIf mongodb.enabled is false , provide the right cosmosDB/DocumentDB endpoint""
    mongodb.image.repositoryContainer repository for mongodb Containerenbuild-staging/vivsoft-platform-ui/mongodb
    mongodb.image.tagContainer tag for mongodb Container4.4.5

    ENBUILD UI Services parameters

    NameDescriptionValue
    enbuildUi.image.repositoryContainer repository for enbuildUienbuild-staging/vivsoft-platform-ui/enbuild-frontend
    enbuildUi.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildUi.replicasContainer enbuildUI Replicas1
    enbuildUi.service_typeenbuildUI service_typeClusterIP
    enbuildUi.node_portenbuildUI node_port30080
    enbuildUi.hostnameenbuild service hostname. enbuildUi.hostname.global.domain becomes your FQDNenbuild
    enbuildUi.kiali_urlkiali_urlhttps://kiali.ijuned.com/kiali/
    enbuildUi.grafana_urlgrafana_urlhttps://grafana.ijuned.com/
    enbuildUi.loki_urlloki_urlhttps://grafana.ijuned.com/d/liz0yRCZz/logs-app?orgId=1
    enbuildUi.kubecost_urlkubecost_urlhttps://kubecost.ijuned.com/overview.html

    ENBUILD Backend Services parameters

    NameDescriptionValue
    enbuildBk.image.repositoryContainer repository for enbuildBkenbuild-staging/vivsoft-platform-ui/enbuild-backend
    enbuildBk.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildBk.replicasContainer enbuildBk Replicas1
    enbuildBk.service_typeenbuildBk service_typeClusterIP
    enbuildBk.encryption_keyencryption_key to be used by Backendencryption_key

    ENBUILD USER Services parameters

    NameDescriptionValue
    enbuildUser.image.repositoryContainer repository for enbuildUserenbuild-staging/vivsoft-platform-ui/enbuild-user
    enbuildUser.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildUser.replicasContainer enbuildUser Replicas1
    enbuildUser.service_typeenbuildUser service_typeClusterIP

    ENBUILD Sync Services parameters

    NameDescriptionValue
    enbuildSync.image.repositoryContainer repository for enbuildSyncenbuild-staging/vivsoft-platform-ui/enbuild-cronjob
    enbuildSync.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildSync.replicasContainer enbuildSync Replicas1

    ENBUILD ML Services parameters

    NameDescriptionValue
    enbuildMl.enabledShould we create the ENBUILD ML microservice ?false
    enbuildMl.image.repositoryContainer repository for enbuildMlenbuild-staging/vivsoft-platform-ui/enbuild-ml
    enbuildMl.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildMl.replicasContainer enbuildMl Replicas1
    enbuildMl.service_typeenbuildMl service_typeClusterIP
    enbuildMl.jupyterhub.enabledShould we create the Jupyterhub for ENBUILD ML ?false

    ENBUILD GenAI Services parameters

    NameDescriptionValue
    enbuildGenAI.enabledShould we create the ENBUILD GenAI microservice ?false
    enbuildGenAI.image.repositoryContainer repository for enbuildGenAIenbuild-staging/vivsoft-platform-ui/enbuild-genai
    enbuildGenAI.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildGenAI.replicasContainer enbuildGenAI Replicas1
    enbuildGenAI.service_typeenbuildGenAI service_typeClusterIP
    enbuildGenAI.api_keyapi_key for OpenAI service.dummy

    ENBUILD Request Services parameters

    NameDescriptionValue
    enbuildRequest.enabledShould we create the ENBUILD Request microservice ?false
    enbuildRequest.image.repositoryContainer repository for enbuildRequestenbuild-staging/vivsoft-platform-ui/enbuild-request
    enbuildRequest.image.tagContainer image tag. Skip to use the HelmChart appVersion as Image Tagundefined
    enbuildRequest.replicasContainer enbuildRequest Replicas1
    enbuildRequest.service_typeenbuildRequest service_typeClusterIP
    Prev
    ENBUILD UI walkthrough
    Next
    ENBUILD Repositories
    \ No newline at end of file diff --git a/search-index.json b/search-index.json index 9f955cb..e975ad6 100644 --- a/search-index.json +++ b/search-index.json @@ -1 +1 @@ -[{"content":"","date":"2023-09-07","id":0,"permalink":"/docs/getting-started/","summary":"","tags":[],"title":"Getting Started"},{"content":"","date":"0001-01-01","id":1,"permalink":"/docs/how-to-guides/","summary":"","tags":[],"title":"How-to Guides"},{"content":"","date":"2023-09-07","id":2,"permalink":"/docs/troubleshooting/","summary":"","tags":[],"title":"Troubleshooting"},{"content":"Test ","date":"2023-09-07","id":3,"permalink":"/docs/faq/","summary":"Test ","tags":[],"title":"FAQ"},{"content":"","date":"2023-09-07","id":4,"permalink":"/docs/references/","summary":"","tags":[],"title":"References"},{"content":"Overview ENBUILD is a cutting-edge software development and engineering tool designed to simplify the complexities of modern-day DevSecOps, containerization and cloud tooling. At its core, ENBUILD offers a self-service catalog featuring pre-packaged templates known as ENBUILD Catalog Items. These templates encompass Terraform Infrastructure deployments on major cloud platforms (AWS, Azure, GCP) and Helm Deployments onto Kubernetes, providing developers with a robust foundation for both infrastructure and application deployment. With automated GitLab and GitHub workflows and pipelines, ENBUILD streamlines the deployment process, allowing developers to focus on value-added work.\nThis tool is specifically tailored for the United States Department of Defense and Government Organizations embarking on DevSecOps Transformation, Cloud Migration, or Platform Development journeys. ENBUILD serves as a strategic accelerator for the adoption of the United States Air Force\u0026rsquo;s Platform One Big Bang Tech Stack, enabling rapid and secure software development and deployment. With seamless integration into popular Continuous Integration / Continuous Deployment engines like GitLab and GitHub, ENBUILD ensures a unified development lifecycle. Moreover, its integration with identity and access management solutions, including Keycloak and Okta, ensures compliance with government regulations through robust Role-Based Access Control (RBAC).\nAs a Kubernetes-native deployment, ENBUILD provides versatility across various Kubernetes environments, supporting AWS EKS, Azure AKS, Rancher, OpenShift, and more. By abstracting toil work and complexities, ENBUILD aims to meet 60-70% of developers\u0026rsquo; needs out of the box, offering a solid starting point for customization and specialization. In summary, ENBUILD stands as a comprehensive solution, empowering organizations to enhance their development processes, accelerate cloud adoption, and navigate the challenges of modern software engineering and infrastructure deployment with ease.\n","date":"2023-09-07","id":5,"permalink":"/docs/getting-started/introduction/","summary":"Overview ENBUILD is a cutting-edge software development and engineering tool designed to simplify the complexities of modern-day DevSecOps, containerization and cloud tooling.","tags":[],"title":"Introduction"},{"content":"\nENBUILD addresses the challenges associated with Day 1 installation and configuration of a Big Bang Kubernetes cluster, offering a streamlined approach for Day 2 operations, including platform upgrades and automation tool patches.\nEase of Use: ENBUILD simplifies Big Bang deployments through a user-friendly UI that facilitates the selection and configuration of DevSecOps pipeline tools. It alleviates common pain points, such as secrets creation and Helm configurations, by utilizing pre-created templates.\nFaster Deployment and Continuous ATO: ENBUILD significantly reduces deployment times, enabling organizations to deploy Big Bang in days rather than weeks or months. It expedites approval processes by leveraging Iron Bank accredited containers.\nOn-Premise \u0026amp; Multi-Cloud Support: ENBUILD provides flexibility by supporting on-premise and cloud deployments across various environments, from edge to commercial Clouds, government Clouds, and air-gapped environments. It allows the deployment of Big Bang stacks on AWS and Azure GovCloud, showcasing cloud-agnostic components.\nOut of the Box Security: Built on pre-hardened DISA compliant containers from Iron Bank, ENBUILD ensures robust security. It incorporates built-in GitOps and Secrets Management for enterprise-grade deployments.\nPre-Built Catalog of Solutions: ENBUILD offers a pre-built catalog featuring solutions for AI/ML deployments using KubeFlow, secure Cloud Computing Architecture based Landing Zones, and data ingestion stacks using Nifi/Kafka/Spark.\nNo Vendor Lock-in: ENBUILD serves as a service delivery accelerator without licensing fees, promoting cost efficiency. It relies on open-source components, fostering a vendor-agnostic approach for greater flexibility and adaptability.\n","date":"2023-09-07","id":6,"permalink":"/docs/getting-started/why-enbuild/","summary":"ENBUILD addresses the challenges associated with Day 1 installation and configuration of a Big Bang Kubernetes cluster, offering a streamlined approach for Day 2 operations, including platform upgrades and automation tool patches.","tags":[],"title":"Why ENBUILD"},{"content":"\nVivSoft is a diverse team of strategists, engineers, designers, and builders\nWHAT WE DO We solve complex organizational challenges, balancing cutting-edge technology with a deep sense of empathy and understanding. We build secure Software Factories based on DoD reference designs and NIST guidelines for Cloud and DevSecOps. These factories deliver AI/ML Applications, Data Science Platforms, Blockchain and Microservices for DoD, Healthcare and Civilian Agencies. ","date":"0001-01-01","id":7,"permalink":"/docs/getting-started/about-vivsoft/","summary":"VivSoft is a diverse team of strategists, engineers, designers, and builders\nWHAT WE DO We solve complex organizational challenges, balancing cutting-edge technology with a deep sense of empathy and understanding.","tags":[],"title":"About Vivsoft"},{"content":"ENBUILD operates as a bridge between developers and the Continuous Integration/Continuous Deployment (CI/CD) systems, specifically with popular platforms like GitHub and GitLab. This tool simplifies the entire software development process, making it accessible and efficient for users with various technical backgrounds.\nGitHub Integration When working with GitHub, ENBUILD seamlessly communicates with the CI/CD provider through REST and GraphQL APIs. It starts by creating a Repository Project, essentially a structured workspace, using a template repository project. The user interacts with ENBUILD through an intuitive user interface (UI), providing inputs that guide the customization of files. These files are then updated based on the user\u0026rsquo;s preferences. Once the configuration is complete, ENBUILD executes the predefined workflow or pipeline, automating the deployment process without the need for intricate manual steps.\nGitLab Integration Similarly, when integrating with GitLab, ENBUILD initiates the process by creating a Repository Project within the GitLab environment. Just like with GitHub, the user\u0026rsquo;s inputs through the ENBUILD UI guide the customization of files within the project. ENBUILD updates these files accordingly, ensuring that the project aligns with the user\u0026rsquo;s specifications. Subsequently, the tool triggers the execution of the workflow or pipeline, seamlessly automating the development and deployment steps.\nIn essence, ENBUILD acts as a facilitator, taking the complexities out of setting up projects and workflows. It empowers users to customize their development environments through a straightforward UI, enabling a smooth and efficient interaction with CI/CD systems like GitHub and GitLab. The result is an accelerated and simplified software development process, allowing developers to focus on building innovative solutions without getting bogged down by technical intricacies.\n","date":"2023-09-07","id":8,"permalink":"/docs/getting-started/how-enbuild-works/","summary":"ENBUILD operates as a bridge between developers and the Continuous Integration/Continuous Deployment (CI/CD) systems, specifically with popular platforms like GitHub and GitLab.","tags":[],"title":"How ENBUILD works"},{"content":"Architecture Digram Frontend Service The ENBUILD frontend service provides the ENBUILD User Interface (UI) to the end user.\nBackend Service The ENBUILD backend service is responsible for integration with the CI/CD Provider.\nUser Service The ENBUILD user service manages the end-user\u0026rsquo;s state, such as authentication, access, API access and role-based access control.\nML Service The ENBUILD ML (Machine Learning) service enables data scientists to quickly create feature sets and deploy models. An instance of Jupyter Notebook can also be created and accessed from this service. (This is a placeholder service for demo purposes for now and will be implemented in the future)\nRequest Service The ENBUILD Request service is demo service to enable linking multiple catalog items to one another and deploy them together. (This is a placeholder service for demo purposes for now and will be implemented in the future)\nRabbitMQ Consumer Service The ENBUILD RabbitMQ consumer service processes jobs in the work queue as well as integrates with the CI/CD Provider APIs.\nNoSQL Database ENBUILD utilizes a NoSQL database to manage the application’s state across all microservices. ENBUILD provides a MongoDB instance out-of-the-box, but also can integrate with Cloud Service Provider NoSQL Databases such as Azure’s CosmosDB and AWS’ DocumentDB.\nIdentity and Access Management ENBUILD supports integration with Okta and Keycloak. Keycloak can act as an Identity Broker for other IdAM products such as Active Directory.\n","date":"2023-09-07","id":9,"permalink":"/docs/getting-started/enbuild-architecture/","summary":"Architecture Digram Frontend Service The ENBUILD frontend service provides the ENBUILD User Interface (UI) to the end user.\nBackend Service The ENBUILD backend service is responsible for integration with the CI/CD Provider.","tags":[],"title":"ENBUILD Architecture"},{"content":"Home Page / Catalogs page Stack List Page Manage Catalog page This page needs admin permission\nBuild ML This page is only visible if the Build ML flag is enabled in the feature flag.\nBuild GenAI This page is only visible if the Build GenAI flag is enabled in the feature flag.\nOperations This page is only visible if the operations flag is enabled in the feature flag.\nMetrics These are the quick metrices Logs These are the logs for your cluster where enbuild is deployed. View Deployment Logs Click on a deployment to view its logs. Create a new deployment Create a new deployment by clicking on the \u0026ldquo;New Deployment\u0026rdquo; button. Settings This page allows you to configure various settings for ENBUILD. ","date":"0001-01-01","id":10,"permalink":"/docs/getting-started/enbuild-ui-walkthrough/","summary":"Home Page / Catalogs page Stack List Page Manage Catalog page This page needs admin permission\nBuild ML This page is only visible if the Build ML flag is enabled in the feature flag.","tags":[],"title":"ENBUILD UI walkthrough"},{"content":"ENBUILD Helm Chart Values The following key value pairs are used to configure ENBUILD.\nParameters Global parameters Name Description Value global.AppVersion [default: \u0026ldquo;\u0026rdquo;] Provide custom appVersion, to override the default one. All the ENBUILD images will be of the same version. To use indidual tag for each service set the tag on per service basis. \u0026quot;\u0026quot; global.domain What domain to use to expose the ENBUILD using istio or Ingress ijuned.com global.disable_tls_gitlab Set to true if you are using self-signed certificates false global.ingress.enabled Should we create the Ingress Resources ? false global.ingress.tls Is Ingress TLS enabled ? false global.ingress.tls_secret If Ingress is TLS enabled, Provide the Secret for the TLS Certificate. \u0026quot;\u0026quot; global.ingress.classname Ingress classname if enabled. \u0026quot;\u0026quot; global.ingress.annotations Ingress annotations if enabled. [] global.istio.enabled Should we create the Istio Resources ? false global.istio.gateway Istio gateway to use for creating Virtual Service. istio-system/main global.image.registry Container registry to pull images from registry.gitlab.com global.image.pullPolicy Container imagePullPolicy Always global.image.registry_credentials if the image.registry is private container registry, provide the credentials {} global.image.registry_credentials.username Container registry Username \u0026quot;\u0026quot; global.image.registry_credentials.password Container registry password \u0026quot;\u0026quot; Jupyterhub Parameters Name Description Value jupyterhub.cull.enabled Deploy Jupyterhub false ENBUILD RabbitMQ parameters Name Description Value rabbitmq.enabled Set to false to use existing RabbitMQ true rabbitmq.replicaCount RabbitMQ replicaCount 1 rabbitmq.auth.username RabbitMQ username admin rabbitmq.auth.password RabbitMQ password SuperSecret rabbitmq.auth.erlangCookie RabbitMQ erlangCookie lamba rabbitmq.host If rabbitmq.enabled is false , provide the right rabbitmq endpoint \u0026quot;\u0026quot; rabbitmq.queue_prefix Queue Prefix for all RabbitMQ Queues enbuild ENBUILD Backend/DB parameters Name Description Value mongodb.enabled Set to true to Deploy the MongoDB. false mongodb.mongo_root_username DB username. If mongodb.enabled this is used to to set the username. Else this is username for existing Cosmos or DocumentDB \u0026quot;\u0026quot; mongodb.mongo_root_password DB Password. If mongodb.enabled this is used to to set the password. Else this is password for existing Cosmos or DocumentDB \u0026quot;\u0026quot; mongodb.mongo_server If mongodb.enabled is false , provide the right cosmosDB/DocumentDB endpoint \u0026quot;\u0026quot; mongodb.image.repository Container repository for mongodb Container enbuild-staging/vivsoft-platform-ui/mongodb mongodb.image.tag Container tag for mongodb Container 4.4.5 ENBUILD UI Services parameters Name Description Value enbuildUi.image.repository Container repository for enbuildUi enbuild-staging/vivsoft-platform-ui/enbuild-frontend enbuildUi.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildUi.replicas Container enbuildUI Replicas 1 enbuildUi.service_type enbuildUI service_type ClusterIP enbuildUi.node_port enbuildUI node_port 30080 enbuildUi.hostname enbuild service hostname. enbuildUi.hostname.global.domain becomes your FQDN enbuild enbuildUi.kiali_url kiali_url https://kiali.ijuned.com/kiali/ enbuildUi.grafana_url grafana_url https://grafana.ijuned.com/ enbuildUi.loki_url loki_url https://grafana.ijuned.com/d/liz0yRCZz/logs-app?orgId=1 enbuildUi.kubecost_url kubecost_url https://kubecost.ijuned.com/overview.html ENBUILD Backend Services parameters Name Description Value enbuildBk.image.repository Container repository for enbuildBk enbuild-staging/vivsoft-platform-ui/enbuild-backend enbuildBk.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildBk.replicas Container enbuildBk Replicas 1 enbuildBk.service_type enbuildBk service_type ClusterIP enbuildBk.encryption_key encryption_key to be used by Backend encryption_key ENBUILD USER Services parameters Name Description Value enbuildUser.image.repository Container repository for enbuildUser enbuild-staging/vivsoft-platform-ui/enbuild-user enbuildUser.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildUser.replicas Container enbuildUser Replicas 1 enbuildUser.service_type enbuildUser service_type ClusterIP ENBUILD Sync Services parameters Name Description Value enbuildSync.image.repository Container repository for enbuildSync enbuild-staging/vivsoft-platform-ui/enbuild-cronjob enbuildSync.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildSync.replicas Container enbuildSync Replicas 1 ENBUILD ML Services parameters Name Description Value enbuildMl.enabled Should we create the ENBUILD ML microservice ? false enbuildMl.image.repository Container repository for enbuildMl enbuild-staging/vivsoft-platform-ui/enbuild-ml enbuildMl.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildMl.replicas Container enbuildMl Replicas 1 enbuildMl.service_type enbuildMl service_type ClusterIP ENBUILD GenAI Services parameters Name Description Value enbuildGenAI.enabled Should we create the ENBUILD GenAI microservice ? false enbuildGenAI.image.repository Container repository for enbuildGenAI enbuild-staging/vivsoft-platform-ui/enbuild-genai enbuildGenAI.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildGenAI.replicas Container enbuildGenAI Replicas 1 enbuildGenAI.service_type enbuildGenAI service_type ClusterIP enbuildGenAI.api_key api_key for OpenAI service. dummy ENBUILD Request Services parameters Name Description Value enbuildRequest.enabled Should we create the ENBUILD Request microservice ? false enbuildRequest.image.repository Container repository for enbuildRequest enbuild-staging/vivsoft-platform-ui/enbuild-request enbuildRequest.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildRequest.replicas Container enbuildRequest Replicas 1 enbuildRequest.service_type enbuildRequest service_type ClusterIP ","date":"0001-01-01","id":11,"permalink":"/docs/getting-started/helm-values/","summary":"ENBUILD Helm Chart Values The following key value pairs are used to configure ENBUILD.\nParameters Global parameters Name Description Value global.","tags":[],"title":"Helm Values"},{"content":"GitLab Resources The following table contains groups and repositories for ENBUILD.\nName Description iac-templates All ENBUILD Catalog Item Templates are located in this Group. vivsoft-platform The vivsoft-platform repository contains the source code for ENBUILD microservices. It is the codebase for building and maintaining the various microservices that collectively form the ENBUILD platform. baseos-rhel8 The basewos-rhel8 repository includes Packer configuration for creating a Red Hat 8 hardened Amazon Machine Image (AMI). It provides the necessary settings and scripts to build a secure and minimal RHEL8 AMI for ENBUILD use. enbuild-packer-rhel8 The enbuild-packer-rhel8 repository contains Packer configuration specifically tailored for creating a minimal ENBUILD AMI. It includes the necessary configuration details for building a lightweight and optimized AMI. hardened-gitlab-runner The hardened-gitlab-runner repository provides Dockerfile configuration for building a GitLab Runner container image with enhanced security measures. It is designed to create a secure environment for CI/CD processes within the ENBUILD ecosystem. enbuild-helm-chart The enbuild-helm-chart repository contains the Helm Chart for deploying ENBUILD. It provides the necessary configurations and definitions for using Helm to deploy and manage ENBUILD components in a Kubernetes environment. GitHub Resources The following table contains groups and repositories for ENBUILD.\nHere\u0026rsquo;s your markdown table for the provided data:\nName Description VivSoftOrg VivSoftOrg is an organizational group that houses all ENBUILD Catalog Item Templates. It serves as a centralized repository for various templates related to ENBUILD. The table includes the Name as a hyperlink directing to the corresponding link and provides a description alongside it.\n","date":"0001-01-01","id":12,"permalink":"/docs/getting-started/enbuild-repositories/","summary":"GitLab Resources The following table contains groups and repositories for ENBUILD.\nName Description iac-templates All ENBUILD Catalog Item Templates are located in this Group.","tags":[],"title":"ENBUILD Repositories"},{"content":"Follow these step-by-step instructions to deploy ENBUILD locally for testing.\nPrerequisites Existing Kubernetes Cluster Ensure that you have access to a Kubernetes cluster and obtain the KubeConfig file.\nYou can use rancher-desktop or k3d to spin up a local Kubernetes cluster.\nENBUILD Container Images Access to the ENBUILD container images are required for this deployment. These images are published to the VivSoft managed container reigistry on registry.gitLab.com. Make sure that you have the necessary credentials to pull these images.\nHelm CLI The Helm streamlines and automates Kubernetes deployments by managing charts, enabling users to easily package, version, and deploy complex applications.\nDeployment Steps: Following are the steps you will need to take to deploy ENBUILD to your Kubernetes cluster.\nAdd ENBUILD Helm Chart Repository To add the ENBUILD Helm chart repository, run the following command:\nhelm repo add vivsoft https://vivsoftorg.github.io/enbuild \u0026#34;vivsoft\u0026#34; has been added to your repositories ❗ Note: If the helm repo is already present on you machine , update it to get the latest version\n❯ helm repo update vivsoft Configure ENBUILD Helm Values Before deploying ENBUILD to the Kubernetes cluster, you will need to create a custom values.yaml file so that we can specify configurations unique to this deployment.\nFor local deployment however we require minimum deployment values.\n❗ Note: For more information about the complete set of ENBUILD Helm values click here!\nRefer to the example helm input file for guidance.\n⚡ Note: The imageCredentials section is only required if the images are not public.\nDeploy ENBUILD HELM Chart Make sure you update the values input to reference the values you created in Step 2. Execute the command below.\nhelm upgrade --install --namespace enbuild enbuild vivsoft/enbuild --create-namespace -f target/quick_install.yaml Release \u0026#34;enbuild\u0026#34; does not exist. Installing it now. NAME: enbuild LAST DEPLOYED: Fri Mar 22 17:37:23 2024 NAMESPACE: enbuild STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: 1. Get the application URL by running these commands: echo \u0026#34;Visit http://127.0.0.1:3000 to use your application after starting the port forward\u0026#34; kubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Validate ENBUILD Deployment Use the following commands to validate the ENBUILD pods are up and running.\nkubectl get pods -n enbuild NAME READY STATUS RESTARTS AGE enbuild-enbuild-genai-8488c86d6f-csfmn 1/1 Running 0 76m enbuild-enbuild-ui-56f5667d5b-4xckt 1/1 Running 0 76m enbuild-mongodb-0 1/1 Running 0 76m enbuild-rabbitmq-0 1/1 Running 0 76m enbuild-enbuild-backend-66676f8cd8-hxtbr 1/1 Running 0 76m enbuild-enbuild-user-b87d95b45-c79p6 1/1 Running 0 76m enbuild-enbuild-request-7c47c6d67b-j2fnd 1/1 Running 1 (73m ago) 76m enbuild-enbuild-ml-6f944ff759-ztdj6 1/1 Running 1 (73m ago) 76m enbuild-rabbitmq-1 1/1 Running 0 73m enbuild-rabbitmq-2 1/1 Running 0 72m enbuild-enbuild-mq-575c965764-zcnlg 1/1 Running 18 (6m24s ago) 76m ❗ Note: You might see restarts of the enbuild-enbuild-mq-* pod until the RabbitMQ service is up and running.\nValidate the ENBUILD services are setup correctly\nkubectl get services -n enbuild NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE enbuild-rabbitmq-headless ClusterIP None \u0026lt;none\u0026gt; 4369/TCP,5672/TCP,25672/TCP,15672/TCP 80s enbuild-mongo ClusterIP 10.43.230.6 \u0026lt;none\u0026gt; 27017/TCP 80s enbuild-enbuild-user ClusterIP 10.43.140.228 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-ui ClusterIP 10.43.110.47 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-backend ClusterIP 10.43.146.20 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-rabbitmq ClusterIP 10.43.54.197 \u0026lt;none\u0026gt; 5672/TCP,4369/TCP,25672/TCP,15672/TCP 80s Access ENBUILD Use the port forwarding command to access the ENBUILD UI using your web browser.\nkubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Forwarding from 127.0.0.1:3000 -\u0026gt; 8080 Forwarding from [::1]:3000 -\u0026gt; 8080 Navigate your web browser to http://127.0.0.1:3000. and set the admin password.\nAfter you set the initial admin password, you should see the ENBUILD home page with BigBang Catalog.\n⚡ Proceed to Configureing ENBUILD\nUninstall ENBUILD Use the following command to uninstall ENBUILD from your Kubernetes cluster.\nhelm uninstall enbuild -n enbuild release \u0026#34;enbuild\u0026#34; uninstalled ","date":"0001-01-01","id":13,"permalink":"/docs/how-to-guides/deploying-enbuild-for-local-testing/","summary":"Steps to deploy ENBUILD on local machine for quick testing","tags":[],"title":"Deploying ENBUILD for Local Testing"},{"content":"Follow these step-by-step instructions to configure ENBUILD.\nAfter you have successfully deployed the ENBUILD Helm Chart, you will need to configure the ENBUILD to deploy the Catalogs.\nSet the Admin Password You need to set the Admin Password before accessing the ENBUILD.\nConfigure the VCS Before deploying the catalog items, you need to configure the Version Control System (VCS). ENBUILD supports GitHub, GitLab VCS as of now.\nThese are the Version Control System where ENBUILD creates repositories when you deploy catalog item\nGITHUB By default , github is not enabled, so first you need to enable github, by clicking in it (only if you are planning to use Github as your VCS), and then set the following settings\nGithub Account \u0026ndash; The Github account where the deployment repositories will be created. Github Token \u0026ndash; The Token to be used to create deployment repositories Github Host \u0026ndash; The Github Host URL (e.g. https://github.com/) Github Branch \u0026ndash; The default branch for the deployment repositories (e.g. main) Github Host GQL URL \u0026ndash; The GraphQL API endpoint for the Github Host (e.g. https://api.github.com/graphql) Github Host URL \u0026ndash; The REST API endpoint for the Github Host (e.g. https://api.github.com) GITLAB Gitlab Host - The Gitlab Host (e.g. https://gitlab.com/) Gitlab Token - Gitlab Token to be used to create deployment repositories Gitlab Group - The Gitlab Group where the deployment repositories will be created Gitlab Namespace ID - The Gitlab Namespace ID of the group or user (e.g. 70306609) ❗ Note: You need to restart the enbuild-enbuild-mq-* pod after changing the VCS (GITHUB and GITLAB) setting.\nCatalog level Permissions There are four built-in roles available in ENBUILD:\nadmin appdev dataops devops You can check the roles by going to Admin \u0026ndash;\u0026gt; Roles\nAnd you can provide the permissions to each catalog as per your requirement for each catalog and roles.\nConfigure SSO By default ENBUILD uses Local authentication, but you can choose to use either of\nKEYCLOAK OKTA Configure KEYCLOAK If you plan to use KEYCLOAK as SSO for authentication, you will need to configure the following:\nKeycloak Backend URL \u0026ndash; The Keycloak URL to authenticate users. Keycloak Client ID \u0026ndash; The Keycloak Client ID to authenticate users. Keycloak Realm \u0026mdash; The Keycloak REALM to authenticate users. ❗ Note: To provide these details, you need to existing keyclaok or you need to install and configure keycloak.\nConfigure OKTA If you plan to use OKTA as SSO for authentication, you will need to configure the following:\nOkta Client URL \u0026ndash; The Okta URL to authenticate users. Okta Client Secret \u0026ndash; The Okta Client Secret to authenticate users. Okta Client ID \u0026mdash; The Okta Client ID to authenticate users. Okta Base URL \u0026mdash; The Okta Base URL to authenticate users. Okta Client Token \u0026mdash; The Okta Client Token to authenticate users. ❗ Note: To provide these details, you need to configure okta and obtain the details.\n","date":"0001-01-01","id":14,"permalink":"/docs/how-to-guides/configuring-enbuild/","summary":"Configuring ENBUILD after installation","tags":[],"title":"Configuring ENBUILD"},{"content":"Follow these step-by-step instructions to deploy ENBUILD locally using Iron Bank images for testing.\nPrerequisites Existing Kubernetes Cluster Ensure that you have access to a Kubernetes cluster and obtain the KubeConfig file.\nYou can use rancher-desktop or k3d to spin up a local Kubernetes cluster.\nHelm CLI The Helm streamlines and automates Kubernetes deployments by managing charts, enabling users to easily package, version, and deploy complex applications.\nAccess to ironbank Vivsoft has released the ENBUILD Container images in Ironbank in order to pull these images, you need to register in Ironbank and create credentials.\nDeployment Steps: Following are the steps you will need to take to deploy ENBUILD to your Kubernetes cluster.\nAdd ENBUILD Helm Chart Repository To add the ENBUILD Helm chart repository, run the following command:\nhelm repo add vivsoft https://vivsoftorg.github.io/enbuild \u0026#34;vivsoft\u0026#34; has been added to your repositories ❗ Note: If the helm repo is already present on you machine , update it to get the latest version\n❯ helm repo update vivsoft Configure ENBUILD Helm Values Before deploying ENBUILD to the Kubernetes cluster, you will need to create a custom values.yaml file so that we can specify configurations unique to this deployment.\nFor local deployment however we require minimum deployment values.\n❗ Note: For more information about the complete set of ENBUILD Helm values click here!\nRefer to the example helm input file to be used to pull images from IronBank for guidance.\nMake sure to replace the REGISTRY1_USER_NAME and REGISTRY1_PASSWORD , with your registry1 credentials. AppVersion with the ENBUILD application version you want to install. ( Make sure the images with the selected tags are present in IronBank)\nDeploy ENBUILD HELM Chart Make sure you update the values input to reference the values you created in Step 2. Execute the command below.\nhelm upgrade --install --namespace enbuild enbuild vivsoft/enbuild --create-namespace -f /tmp/quick_install_ib.yaml Release \u0026#34;enbuild\u0026#34; does not exist. Installing it now. NAME: enbuild LAST DEPLOYED: Fri Mar 22 17:37:23 2024 NAMESPACE: enbuild STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: 1. Get the application URL by running these commands: echo \u0026#34;Visit http://127.0.0.1:3000 to use your application after starting the port forward\u0026#34; kubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Validate ENBUILD Deployment Use the following commands to validate the ENBUILD pods are up and running.\nkubectl get pods -n enbuild NAME READY STATUS RESTARTS AGE enbuild-enbuild-genai-8488c86d6f-csfmn 1/1 Running 0 76m enbuild-enbuild-ui-56f5667d5b-4xckt 1/1 Running 0 76m enbuild-mongodb-0 1/1 Running 0 76m enbuild-rabbitmq-0 1/1 Running 0 76m enbuild-enbuild-backend-66676f8cd8-hxtbr 1/1 Running 0 76m enbuild-enbuild-user-b87d95b45-c79p6 1/1 Running 0 76m enbuild-enbuild-request-7c47c6d67b-j2fnd 1/1 Running 1 (73m ago) 76m enbuild-enbuild-ml-6f944ff759-ztdj6 1/1 Running 1 (73m ago) 76m enbuild-rabbitmq-1 1/1 Running 0 73m enbuild-rabbitmq-2 1/1 Running 0 72m enbuild-enbuild-mq-575c965764-zcnlg 1/1 Running 18 (6m24s ago) 76m ❗ Note: You might see restarts of the enbuild-enbuild-mq-* pod until the RabbitMQ service is up and running.\nValidate the ENBUILD services are setup correctly\nkubectl get services -n enbuild NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE enbuild-rabbitmq-headless ClusterIP None \u0026lt;none\u0026gt; 4369/TCP,5672/TCP,25672/TCP,15672/TCP 80s enbuild-mongo ClusterIP 10.43.230.6 \u0026lt;none\u0026gt; 27017/TCP 80s enbuild-enbuild-user ClusterIP 10.43.140.228 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-ui ClusterIP 10.43.110.47 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-backend ClusterIP 10.43.146.20 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-rabbitmq ClusterIP 10.43.54.197 \u0026lt;none\u0026gt; 5672/TCP,4369/TCP,25672/TCP,15672/TCP 80s Access ENBUILD Use the port forwarding command to access the ENBUILD UI using your web browser.\nkubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Forwarding from 127.0.0.1:3000 -\u0026gt; 8080 Forwarding from [::1]:3000 -\u0026gt; 8080 Navigate your web browser to http://127.0.0.1:3000. and set the admin password.\nAfter you set the initial admin password, you should see the ENBUILD home page with BigBang Catalog.\n⚡ Proceed to Configureing ENBUILD\nUninstall ENBUILD Use the following command to uninstall ENBUILD from your Kubernetes cluster.\nhelm uninstall enbuild -n enbuild release \u0026#34;enbuild\u0026#34; uninstalled ","date":"0001-01-01","id":15,"permalink":"/docs/how-to-guides/deploying-enbuild-using-ironbank-images/","summary":"Steps to deploy ENBUILD Using IronBank Images on local machine for quick testing","tags":[],"title":"Deploying ENBUILD Using IronBank Images"},{"content":"Bigbang Big Bang is a declarative, continuous delivery tool for deploying DoD hardened and approved packages into a Kubernetes cluster. More details are found Here\nPrerequisites Before you begin, ensure that you have the following prerequisites in place:\nIt does not matter how you create the kubernetes cluster , but you should have access to kubeconfig file. The cluster also have enough resources ( memory/cpu/) to run the bigbang nodes. The cluster-api server should be publicly accessible so that public gitlab ci-cd can access it. Once you deploy EKS or RKE2 from ENBUILD , it creates the SOPS KMS key. Once created and note down the ARN of the KMS key generated and create the sops.yaml file in below format , changing the ADD_YOUR_KMS_KEY_ARN_HERE with your actual SOPS KMS key.\nThis file we will use whole deploying BigBang.\n--- creation_rules: - kms: ADD_YOUR_KMS_KEY_ARN_HERE encrypted_regex: \u0026#34;^(data|stringData)$\u0026#34; Variables of creation_rules kms (string)\nDescription: The Amazon Resource Name (ARN) of the KMS key to be used for encryption. Default value: \u0026quot;ADD_YOUR_KMS_KEY_ARN_HERE\u0026quot; encrypted_regex (string)\nDescription: The regular expression pattern used to identify fields that should be encrypted. Default value: \u0026quot;^(data|stringData)$\u0026quot; Deploy BigBang Login to Enbuild -Enbuild Click on the Home Select the Platform One BigBang At the SOPS tab provide the sops.yaml created on SOPS prerequisite section. At the REPO tab , provide the\nRegistry URL — The container registry from where you are pulling the images for flux deployment. Registry Username - The container registry username to pull flux images Registry Password - The container registry password to pull flux images Repository Username - The gitlab repository username to pull the BigBang Helm chart. We have cloned the chart at chart Repository Password - The gitlab repository password to pull the BigBang Helm chart. (We have cloned the chart at chart) Next, choose the component Repo from the settings category and click on the SECRETS tab and provide the registryCredentialsand git credentials this is basically used by BigBang Helm chart to pull the container images and cloning the dependant helm charts used by bigbang.\nThe values of these will be same as previous section. registryCredentials: registry: registry.gitlab.com username: registry_username password: registry_password email: \u0026#34;\u0026#34; git: credentials: username: repository_usernane password: registry_password Similarly you can check other components and edit the values of the component deployment. If you feel the value is sensitive you can add that in secrets tab, so that enbuild will encrypt it using the KMS key provided before committing to the git repo. The different types of components avalable are listed below: settings Tool Repo -Domain used for BigBang created exposed services, can be overridden by individual packages. Service Mesh Tools Istio - Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments. Istio Operator - Instead of manually installing, upgrading, and uninstalling Istio, you can instead let the Istio operator manage the installation for you. This relieves you of the burden of managing different istioctl versions. Simply update the operator custom resource (CR) and the operator controller will apply the corresponding configuration changes for you. Jaeger - Distributed tracing observability platforms, such as Jaeger, are essential for modern software applications that are architected as microservices. Jaeger maps the flow of requests and data as they traverse a distributed system. These requests may make calls to multiple services, which may introduce their own delays or errors. Jaeger connects the dots between these disparate components, helping to identify performance bottlenecks, troubleshoot errors, and improve overall application reliability. Jaeger is 100% open source, cloud native, and infinitely scalable. Kiali - Kiali is a console for Istio service mesh. Kiali can be quickly installed as an Istio add-on, or trusted as a part of your production environment. Security Tools NeuVector - NeuVector is the only 100% open source, Zero Trust container security platform. Continuously scan throughout the container lifecycle. Remove security roadblocks. Bake in security policies at the start to maximize developer agility.\nFortify - Fortify is a comprehensive application security (AppSec) platform developed by Micro Focus. It empowers organizations to proactively identify and address vulnerabilities throughout the entire software development lifecycle (SDLC). Think of it as a security shield woven into the fabric of your development process, helping you build secure software from the ground up.\nTwistLock - Twistlock, now known as Palo Alto Networks Prisma Cloud, is a comprehensive cloud-native security platform designed to protect containerized applications and serverless workloads across cloud environments\nAnchore - Anchore is a container security and compliance platform that helps organizations discover, analyze, and enforce security and compliance policies for containerized applications and images. It ensures that container images are free from vulnerabilities and meet security and compliance standards before they are deployed.\nVault - Vaults work by encrypting each secret to help prevent unauthorized users from gaining access. They function mostly as an active storage container for secrets as well as an account management system for dealing with multiple privileged accounts across the company.\nSSO Tools Auth Service - An authentication service is an identity verification mechanism—similar to passwords—for apps, websites, or software systems. Keycloak - Keycloak is the standalone tool for identity and access management, which allows us to create a user database with custom roles and groups. We can use this information further to authenticate users within our application and secure parts of it based on predefined roles. Policy Management Tools Kyverno - Kyverno is a policy engine designed for Kubernetes platform engineering teams. It enables security, automation, compliance, and governance using policy-as-code. Kyverno Reporter - Monitoring and Observability Tool for the PolicyReport CRD with an optional UI. Kyverno Policies - Kyverno policies can validate, mutate, generate, and cleanup Kubernetes resources, and verify image signatures and artifacts to help secure the software supply chain. Cluster Auditor - Cluster Auditor is a tool that pulls constraints from the Kubernetes API, transforms them, and inserts them into Prometheus to be displayed in a Grafana Dashboard. Gatekeeper - Gatekeeper HQ is a vendor and contract lifecycle management platform designed for companies of all sizes. It offers a secure contract and vendor repository that stores every file, interaction, and piece of metadata relating to all your contract agreements. The platform provides features for vendor management, contract management, Kanban workflow, collaboration, and reporting, with the ability to extend functionality through additional modules and integration with over 220 third-party solutions. Logging Tools ECK operator - The ECK operator, or Elastic Cloud on Kubernetes, is built on the Kubernetes Operator pattern. It extends Kubernetes’ orchestration capabilities to support the setup and management of various Elastic Stack components on Kubernetes, including Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, and Logstash Fluentbit - Fluent Bit is a super fast, lightweight, and highly scalable logging and metrics processor and forwarder. It is the preferred choice for cloud and containerized environments. EFK stack -The EFK stack is a popular open-source logging solution for Kubernetes environments. It stands for: Elasticsearch: A search and analytics engine. Fluentd: An open-source data collector for unified logging layer. Kibana: A visualization dashboard for Elasticsearch. Loki - Grafana Loki is a set of open source components that can be composed into a fully featured logging stack. A small index and highly compressed chunks simplifies the operation and significantly lowers the cost of Loki. Promtail - Promtail is an agent which ships the contents of local logs to a private Grafana Loki instance or Grafana Cloud. It is usually deployed to every machine that runs applications which need to be monitored. Monitoring Tools Monitoring - Together, these tools provide a powerful platform for aggregating, analyzing, and visualizing logs in Kubernetes clusters, helping with monitoring, troubleshooting, and gaining insights from applications. Thanos - Thanos is based on Prometheus. With Thanos, Prometheus always remains as an integral foundation for collecting metrics and alerting using local data. Tempo - Tempo is an open source, easy-to-use, and high-scale distributed tracing backend. Sonarqube - SonarQube is a self-managed, automatic code review tool that systematically helps you deliver Clean Code. As a core element of our Sonar solution. Tempo - Tempo is an open source, easy-to-use, and high-scale distributed tracing backend. Grafana - Grafana is the open source analytics \u0026amp; monitoring solution for every database. Metrics Server - The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it isn\u0026rsquo;t deployed by default in Amazon EKS clusters. Development Tools Sonarqube - SonarQube is a self-managed, automatic code review tool that systematically helps you deliver Clean Code. As a core element of our Sonar solution.\nNexus - Nexus is a robust tool designed for managing and organizing artifacts throughout the software development lifecycle.\nHarbor - Harbor is an open source registry that secures artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. Harbor, a CNCF Graduated project, delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud native compute platforms like Kubernetes and Docker.\nGitLab- GitLab is a web-based DevOps lifecycle tool that integrates various stages of the software development process into a single platform.\nCI/CD Tools ArgoCD - Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. GitLab Runner - GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline. Proxy Tool Haproxy - HAProxy is a free, open source high availability solution, providing load balancing and proxying for TCP and HTTP-based applications by spreading requests across multiple servers. Backup Tool: Velero - Velero is an open source tool to safely backup and restore, perform disaster recovery, and migrate Kubernetes cluster resources and persistent volumes. Object Storage Tools: Minio - MinIO is a high-performance, S3 compatible object store. It is built for large scale AI/ML, data lake and database workloads. It is software-defined and runs on any cloud or on-premises infrastructure. MinIO is dual-licensed under open source GNU AGPL v3 and a commercial enterprise license. Minio Operator - The MinIO Operator installs a Custom Resource Definition (CRD) to support describing MinIO tenants as a Kubernetes object. See the MinIO Operator CRD Reference for complete documentation on the MinIO CRD. Communication Tools Mattermost - Mattermost is a secure collaboration platform for accelerating mission critical work in complex environments. Metrics Server - The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it isn\u0026rsquo;t deployed by default in Amazon EKS clusters. One important component setting while deploying BigBang is\ndomain: dev.bigbang.mil which is present in Settings → Repo → Values. This defines the istio ingress domain on which the bigbang applications will be available.\nYou also have to provide the right tls certificate and key for the same domain defined above in the Component → Service Mesh → Istio → Secrets tab. So that you can access the bigbang applications in browser without any security/certificate warning.\nAfter providing all the input values, provide the name for your deployment proceed to Infrastructure section, and provide your kubeconfig file - Paste your kubeconfig file Select AWS as your cloud and provide your AWS credentials. These AWS credentials are used to encrypt the secrets using SOPS. So make sure the IAM user of these credentials is having kms:Encrypt and kms:Decrypt permissions. Once all inputs are provided click on Deploy Stack\n","date":"0001-01-01","id":16,"permalink":"/docs/how-to-guides/deploying-bigbang/","summary":"Steps to Deploy Bigbang","tags":[],"title":"Deploying Bigbang"},{"content":"Kubernetes Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management.Originally designed by Google, the project is now maintained by a worldwide community of contributors, and the trademark is held by the Cloud Native Computing Foundation.\nDeploy Kubernetes Login to Enbuild -Enbuild Click on the Home Select the Kubernetes Choose the component RKE2 from the DISTRO category and click on the VALUES tab and provide the Credentials RKE2 RKE2, also known as RKE Government, is Rancher\u0026rsquo;s next-generation Kubernetes distribution.\nIt is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.\nDeploy RKE2 VPC Configuration create_vpc (true or false)\nDescription: The create_vpc variable decides if a new Virtual Private Cloud (VPC) should be created. Default value: false vpc_cidr (string)\nDescription: The vpc_cidr variable defines the IP address range for the VPC. Default value: \u0026quot;10.0.0.0/16\u0026quot; NAT Gateway Configuration enable_nat_gateway (true or false)\nDescriprion: The enable_nat_gateway variable decides if a NAT Gateway should be enabled. Default value: true single_nat_gateway (true or false)\nDescription: The single_nat_gateway decides if only one NAT Gateway should be used. Default value: true vpc_id (string)\nDescription: The vpc_id is used to Specify an existing VPC to use. Needed if create_vpc is false. Default value:: \u0026quot;vpc-39b8da44\u0026quot; subnets (list of strings)\nDescription: Lists the IDs of subnets within the VPC. Needed if create_vpc is false. Example: [\u0026quot;subnet-5817463e\u0026quot;, \u0026quot;subnet-f191cdd0\u0026quot;] EC2 Instance Configuration instance_type (string)\nDescription: The instance_type specifies the type of EC2 instance to use. Default value: \u0026quot;t3.large\u0026quot; associate_public_ip_address (true or false)\nDescription: The associate_public_ip_address decides if the instance should have a public IP address. Default value: true controlplane_internal (true or false)\nWhat it does: Decides if the control plane should be internal only. Default value: false servers (number)\nDescription: Number of EC2 instances to create. Default value: 1 Auto Scaling Group (ASG) Configuration asg (object) Description: The variable asgis used to the Auto Scaling Group (ASG). Properties: min (number): Minimum number of instances in the ASG. Default value: 1 max (number): Maximum number of instances in the ASG. Default value: 10 desired (number): Desired number of instances in the ASG. Default value: 1 suspended_processes (list of strings): List of processes to suspend. Default value: [] termination_policies (list of strings): List of termination policies. Default value: [\u0026quot;Default\u0026quot;] Block Device Mapping block_device_mappings (object) What it does: Configuration for the block device (storage). Properties: size (number): Size of the volume in GB. Default value: 50 type (string): Type of the volume. Default value: \u0026quot;gp2\u0026quot; Registry Mirror Configuration create_registry1_mirror (true or false)\nDescription: create_registry1_mirror decides if a mirror for the https://registry1.dso.mil container registry should be created. Default value: false registry1_mirror_proxy_address (string)\nDescription: This address should have a proper container registry up and running and listening Example: \u0026quot;http://44.210.192.97:5000\u0026quot; After providing all the input values, provide the name for your deployment proceed to Infrastructure section,\nSelect AWS as your cloud and provide your AWS credentials.\nOnce all inputs are provided click on Deploy Stack\nChoose the component EKS from the DISTRO category and follow the previous steps. EKS Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service to run Kubernetes in the AWS cloud and on-premises data centers. In the cloud, Amazon EKS automatically manages the availability and scalability of the Kubernetes control plane nodes responsible for scheduling containers, managing application availability, storing cluster data, and other key tasks. With Amazon EKS, you can take advantage of all the performance, scale, reliability, and availability of AWS infrastructure, as well as integrations with AWS networking and security services. On-premises, EKS provides a consistent, fully-supported Kubernetes solution with integrated tooling and simple deployment to AWS Outposts, virtual machines, or bare metal servers.\nDeploy EKS VPC Configuration create_vpc (true or false)\nDescription: The create_vpc variable decides if a new Virtual Private Cloud (VPC) should be created. Default value: true vpc_cidr (string)\nDescription: The vpc_cidr variable defines the IP address range for the VPC. Default value: \u0026quot;10.0.0.0/16\u0026quot; If you don\u0026rsquo;t want to create a new VPC, set create_vpc to false and provide the following variables:\nvpc_id (string)\nDescription: The vpc_id specifies an existing VPC to use. Needed if create_vpc is false. Example: \u0026quot;vpc-39b8da44\u0026quot; subnet_ids (list of strings)\nDescription: Lists the IDs of subnets within the VPC. Needed if create_vpc is false. Example: [\u0026quot;subnet-1242491c\u0026quot;, \u0026quot;subnet-5817463e\u0026quot;] EKS Cluster Configuration cluster_name (string)\nDescription: The cluster_name variable specifies the name of the EKS cluster. Default value: \u0026quot;juned-eks\u0026quot; cluster_version (string)\nDescription: The cluster_version variable specifies the version of the EKS cluster. Default value: \u0026quot;1.29\u0026quot; cluster_endpoint_public_access (true or false)\nDescription: The cluster_endpoint_public_access variable decides if the EKS cluster endpoint should be publicly accessible. Default value: true cluster_endpoint_private_access (true or false)\nDescription: The cluster_endpoint_private_access variable decides if the EKS cluster endpoint should be privately accessible. Default value: false EKS Node Groups Configuration eks_node_groups_min_size (number)\nDescription: The eks_node_groups_min_size variable specifies the minimum number of nodes in the EKS node group. Default value: 1 eks_node_groups_max_size (number)\nDescription: The eks_node_groups_max_size variable specifies the maximum number of nodes in the EKS node group. Default value: 5 eks_node_groups_desired_size (number)\nDescription: The eks_node_groups_desired_size variable specifies the desired number of nodes in the EKS node group. Default value: 1 NAT Gateway Configuration enable_nat_gateway (true or false)\nDescription: The enable_nat_gateway variable decides if a NAT Gateway should be enabled. Default value: true single_nat_gateway (true or false)\nDescription: The single_nat_gateway variable decides if only one NAT Gateway should be used. Default value: true Kubernetes Configuration create_kubeconfig (true or false) Description: The create_kubeconfig variable decides if a kubeconfig file should be created for the EKS cluster. Default value: true EC2 Instance Configuration instance_types (list of strings) Description: The instance_types variable specifies the types of EC2 instances to use for the EKS nodes. Default value: [\u0026quot;t3.large\u0026quot;] Registry Mirror Configuration create_registry1_mirror (true or false)\nDescription: The create_registry1_mirror variable decides if a mirror for the https://registry1.dso.mil container registry should be created. Default value: false registry1_mirror_proxy_address (string)\nDescription: The registry1_mirror_proxy_address variable specifies the proxy address for the registry1 mirror. Example: \u0026quot;http://44.210.192.97:5000\u0026quot; ","date":"0001-01-01","id":17,"permalink":"/docs/how-to-guides/deploying-kubernetes/","summary":"Steps to Deploy Kubernets","tags":[],"title":"Deploying Kubernetes"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nAccess to Platform1 registry Kubernetes cluster is up and running and you have access to it via kubectl command. Helm 3 installed on your system. Login to Platform1 registry Login to Platform1 registry by using the following command:\nhelm registry login registry1.dso.mil/bigbang WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config Username: Juned_Memon Password: Login Succeeded Create Namespace and Image pull secret We need to create the istio-system and istio-operator namespaces.\nkubectl create ns istio-operator kubectl create ns istio-system Next, we need to create the imagePullSecret for pulling the images from Platform1 registry.\nFirst export the REGISTRY1_USER and REGISTRY1_PASSWORD with your P1 credentials.\nexport REGISTRY1_USER=\u0026lt;YOUR_REGISTRY1_USER\u0026gt; export REGISTRY1_PASSWORD=\u0026lt;YOUR_REGISTRY1_PASSWORD\u0026gt; Next, create the imagePullSecret for pulling the images from Platform1 registry.\nkubectl create secret -n istio-operator docker-registry private-registry --docker-server=registry1.dso.mil --docker-username=$REGISTRY1_USER --docker-password=$REGISTRY1_PASSWORD kubectl create secret -n istio-system docker-registry private-registry --docker-server=registry1.dso.mil --docker-username=$REGISTRY1_USER --docker-password=$REGISTRY1_PASSWORD Install istio-operator Helm charts Now install istio-operator Helm charts using the P1 Helm chart:\nhelm upgrade --install --namespace istio-operator istio-operator oci://registry1.dso.mil/bigbang/istio-operator --version 1.20.4-bb.0 --set imagePullSecrets[0]=\u0026#34;private-registry\u0026#34; --set createNamespace=false Verify the istio-operator pod is up and running:\n# kubectl get po -n istio-operator NAME READY STATUS RESTARTS AGE istio-operator-7b5fff8cfb-h6w4k 1/1 Running 0 18s Optional - Install CertManager Before installing the stio-controlplane we need a wildcard-cert secret containing the SSL certificate for the domain on which are planning to expose the virtual services.\nYou can use CertManager manage that TLS certificates and keys, or you can create them manually using openssl.\nHere, we will install CertManager and use self-signed-certificat.\nTo deploy a proper certificate using CertManager refer the official Documentation\nkubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml # kubectl get pods --namespace cert-manager NAME READY STATUS RESTARTS AGE cert-manager-67c98b89c8-g428w 1/1 Running 0 5m12s cert-manager-cainjector-5c5695d979-7qczq 1/1 Running 0 5m12s cert-manager-webhook-7f9f8648b9-2bt85 1/1 Running 0 5m12s Create a self signed cluster issuer\n--- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned-ca-issuer spec: selfSigned: {} --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: selfsigned-ca namespace: cert-manager spec: isCA: true commonName: selfsigned-ca secretName: root-secret privateKey: algorithm: ECDSA size: 256 issuerRef: name: selfsigned-ca-issuer kind: ClusterIssuer group: cert-manager.io --- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned spec: ca: secretName: root-secret --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: self-sign-cert namespace: istio-system spec: secretName: wildcard-cert commonName: ijuned.com dnsNames: - ijuned.com - \u0026#34;*.ijuned.com\u0026#34; issuerRef: name: selfsigned kind: ClusterIssuer --- Apply the configurations\nkubectl apply -f self-sign-cert.yaml Install istio-controlplane Before installing the stio-controlplane we need a wildcard-cert secret containing the SSL certificate for the domain on which are planning to expose the virtual services.\nYou can create them manaully if you have the tls.key and tls.cert of your private certificate.\nOtherwise you can use Certmanager\nTo install the istio controlplane Helm chart.\nThe domain input that you provide, will be used to create a host entry in the istio Gateway named main\nhelm upgrade --install --namespace istio-system istio oci://registry1.dso.mil/bigbang/istio --version 1.20.4-bb.0 --set imagePullSecrets[0]=\u0026#34;private-registry\u0026#34; --set domain=\u0026#34;ijuned.com\u0026#34; ","date":"0001-01-01","id":18,"permalink":"/docs/how-to-guides/installing-istio/","summary":"Steps to Install Istio","tags":[],"title":"Installing Istio"},{"content":"Creating an AWS EC2 Instance Using the ENBUILD AMI or Marketplace Item This guide will walk you through the steps to create an Amazon EC2 instance using the AMI named ENBUILD.\nThe ENBUILD AMI has ENBUILD pre-installed in it, along with the gitlab.\nThe Gitlab also has Catalog repositories of BigBang and EKS pre-populated with it.\nPrerequisites An AWS account with the necessary permissions to create EC2 instances. Basic familiarity with the AWS Management Console. Steps 1. Log in to the AWS Management Console Go to AWS Management Console. Enter your AWS account credentials to log in. 2. Navigate to the EC2 Dashboard In the AWS Management Console, type \u0026ldquo;EC2\u0026rdquo; in the search bar and select EC2 from the dropdown list. This will take you to the EC2 Dashboard. 3. Launch an Instance On the EC2 Dashboard, click on the Launch Instance button. 4. Choose an Amazon Machine Image (AMI) In the Choose an Amazon Machine Image (AMI) step, go to the My AMIs tab or AWS Marketplace AMI\u0026rsquo;s Use the search bar to find the AMI named ENBUILD. Select the ENBUILD AMI by clicking the Select button next to it. 5. Choose an Instance Type Select an appropriate instance type based on your requirements (e.g., t2.micro for free tier eligible users). Click the Next: Configure Instance Details button. 6. Configure Instance Details Configure the instance details as needed. The default settings are typically sufficient for most users. Click the Next: Add Storage button. 7. Add Storage Adjust the storage settings if necessary. The default settings usually suffice. Click the Next: Add Tags button. 8. Add Tags (Optional) Add tags to your instance to help organize and manage your resources. Click the Next: Configure Security Group button. 9. Configure Security Group Create a new security group or select an existing one. If creating a new security group, add rules to allow necessary inbound traffic (e.g., SSH for Linux instances, RDP for Windows instances). Click the Review and Launch button. 10. Review and Launch Review your instance configuration to ensure everything is correct. Click the Launch button. 11. Select a Key Pair In the Select an existing key pair or create a new key pair dialog: Select an existing key pair, or Create a new key pair and download the private key file (.pem). Make sure to keep this file safe, as you will need it to connect to your instance. Check the acknowledgment box and click the Launch Instances button. 12. View Your Instance Click the View Instances button to go to the EC2 Dashboard and view your newly created instance. Wait for the instance to enter the running state. 13. Connect to Your Instance Select your instance in the EC2 Dashboard. Click the Connect button and follow the instructions to connect to your instance using SSH (for Linux instances) or RDP (for Windows instances). Congratulations! You have successfully launched an EC2 instance using the ENBUILD AMI.\nAccessing Services of ENBUILD The services can be accessed after launching the instance using the AMI at the following URLs with the given public IP (NODE_PUBLIC_IP) of the node:\nEnbuild: http://NODE_PUBLIC_IP:30080/ Gitlab: http://NODE_PUBLIC_IP:32080/ Hauler: http://NODE_PUBLIC_IP:30500/v2/_catalog Default credentials for Gitlab are root/supersecretpassword, and the token for the root user is glpat-RuJrDn4yUuPRJySjJdZh.\nAdditional Resources AWS EC2 Documentation AWS AMI Documentation If you encounter any issues or have questions, refer to the AWS documentation or seek support from AWS.\n","date":"0001-01-01","id":19,"permalink":"/docs/how-to-guides/using-enbuild-ami/","summary":"Steps to use ENBUILD AMI to launch ENBUILD instance","tags":[],"title":"Using ENBUILD AMI"},{"content":"Introduction: In production Kubernetes environments, exposing the ENBUILD UI service requires careful consideration to ensure accessibility and security. While the Quick install of ENBUILD facilitates local testing through port forwarding, deploying in a production scenario demands a more robust approach. This document outlines various options available for exposing the ENBUILD UI service outside the Kubernetes cluster.\nOption 1: Expose UI using Kubernetes Service Type LoadBalancer Setting the service type to LoadBalancer enables external access to the ENBUILD UI service. Simply configure the service type as LB to allow external traffic. Refer to the example helm input file for guidance.\nOption 2: Use Service Type NodePort Configuring the service type as NodePort provides accessibility by exposing a specific port on all nodes in the cluster. Access the ENBUILD UI using the designated node port.\nRefer to the example helm input file for guidance.\nOption 3: Use Ingress Controller Installation and configuration of an Ingress controller within the Kubernetes cluster are prerequisites for this option. Expose the ENBUILD UI service through Ingress configuration for enhanced routing and management of external traffic. Refer to the example helm input file for guidance.\nOption 4: Expose Using Istio Virtual Service (Istio installation)[(docs/how-to-guides/installing-istio/)] and configuration are required for leveraging this option. Set the istio.enabled parameter to true and provide the necessary configurations, such as the Istio Virtual Service, to expose the ENBUILD UI service. Refer to the example helm input file for guidance.\n","date":"0001-01-01","id":20,"permalink":"/docs/how-to-guides/exposing-enbuild-ui/","summary":"Steps to Install Istio","tags":[],"title":"Exposing ENBUILD UI"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nAccess to Platform1 registry Kubernetes cluster is up and running and you have access to it via kubectl command. Helm 3 installed on your system. Login to Platform1 registry Login to Platform1 registry by using the following command:\nhelm registry login registry1.dso.mil/bigbang WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config Username: Juned_Memon Password: Login Succeeded Create Namespace and Image pull secret We need to create the keycloak namespace\nkubectl create ns keycloak Next, we need to create the imagePullSecret for pulling the images from Platform1 registry.\nFirst export the REGISTRY1_USER and REGISTRY1_PASSWORD with your P1 credentials.\nexport REGISTRY1_USER=\u0026lt;YOUR_REGISTRY1_USER\u0026gt; export REGISTRY1_PASSWORD=\u0026lt;YOUR_REGISTRY1_PASSWORD\u0026gt; Next, create the imagePullSecret for pulling the images from Platform1 registry.\nkubectl create secret -n keycloak docker-registry private-registry --docker-server=registry1.dso.mil --docker-username=$REGISTRY1_USER --docker-password=$REGISTRY1_PASSWORD Install keycloak Helm charts Now install keycloak Helm charts using the P1 Helm chart:\nCreate a keycloak-input-values.yaml\n## Overrides the default args for the Keycloak container args: - \u0026#34;start\u0026#34; - \u0026#34;--http-port=8080\u0026#34; - \u0026#34;--import-realm\u0026#34; # Additional environment variables for Keycloak # https://www.keycloak.org/server/all-config extraEnv: |- - name: KC_HTTP_ENABLED value: \u0026#34;true\u0026#34; - name: KC_PROXY value: edge - name: KC_HOSTNAME_STRICT value: \u0026#34;false\u0026#34; - name: KC_HOSTNAME_STRICT_HTTPS value: \u0026#34;false\u0026#34; - name: KC_HTTP_RELATIVE_PATH value: /auth helm upgrade --install --namespace keycloak keycloak oci://registry1.dso.mil/bigbang/keycloak --version 23.0.7-bb.2 -f keycloak-input-values.yaml Verify the keycloak pod is up and running:\n# kubectl get po -n keycloak NAME READY STATUS RESTARTS AGE keycloak-0 1/1 Running 0 105s keycloak-postgresql-0 1/1 Running 0 16m Access keycloak UI Access the Keycloak web interface using Port forwarding\n❯ kubectl port-forward svc/keycloak-http 9090:80 -n keycloak Forwarding from 127.0.0.1:9090 -\u0026gt; 8080 Forwarding from [::1]:9090 -\u0026gt; 8080 Handling connection for 9090 Handling connection for 9090 Handling connection for 9090 Get the Keycloak admin credentials Use the following command to get the admin credentials for the keycloak instance:\nUSER=$(kubectl get secret keycloak-env -n keycloak -o jsonpath=\u0026#39;{.data.KEYCLOAK_ADMIN_PASSWORD}\u0026#39; | base64 --decode) PASSWORD=$(kubectl get secret keycloak-env -n keycloak -o jsonpath=\u0026#39;{.data.KEYCLOAK_ADMIN}\u0026#39; | base64 --decode) echo \u0026#34;Keycloak Admin user is $USER and password is $PASSWORD\u0026#34; Configure the Keycloak Create a realm keyclaok realm is a logical container for a set of related users, applications, and groups.\nAccess the http://localhost:9090/auth/admin/#/realms and click on Add realm.\nTo save we have provided a realm.json file. All you have to do is import it.\nClick on the Browse button and provide the realm.json file. Create a enbuild-ui Client Clients are entities that can request Keycloak to authenticate a user. Most often, clients are applications and services that want to use Keycloak to secure themselves and provide a single sign-on solution.\nClients can also be entities that just want to request identity information or an access token so that they can securely invoke other services on the network that are secured by Keycloak.\nClick on the Clients menu from the left pane. All the available clients for the selected Realm will get listed here.\nRather creating Clients manually we will use Import so that the you do not have provide the details manually.\nTo create a new client, click on Import client.\nClick on the Browse button and provide the enbuild-ui.jsonfile.\nand Save the client.\nAfter import make sure you configure the valid redirect URI\u0026rsquo;s.\nYou have to provide the URI(FQDN) of ENBUILD that you have configured while installing the ENBUILD Helm chart.\nCreate a enbuild Client Use the same method to Import the enbuild.json client.\nAfter you save the enbuild client. Go to the Credentials tab of the enbuild client to get the Client Secret which is required for configuring the (Keycloak in ENBUILD admin setting)[../configuring-enbuild/#configure-keycloak]\nRealm Roles and Groups ❗ Note: All these roles and groups are already created in the realm, when we imported the realms.\nENBUILD support different roles , and based on these roles, differnt type of catalog can be visible.\nBy default\nENBUILD_ADMIN ENBUILD-APPDEV ENBUILD-DATAOPS ENBUILD-DEVOPS ENBUILD_USER these Groups are present in the realm we imported.\nThese Groups mapped to the following roles in one to one relationship.\nadmin \u0026ndash; ENBUILD_ADMIN appdev \u0026ndash; ENBUILD-APPDEV dataops \u0026ndash; ENBUILD-DATAOPS devops \u0026ndash; ENBUILD-DEVOPS user \u0026ndash; ENBUILD_USER Create Users Users are entities that are able to log into your system. They can have attributes associated with themselves like email, username, address, phone number, and birth day. They can be assigned group membership by clicking on the Join Groups button or Groups tab from the profile.\nClick on the Add Member button and select the group you want to add the user to, then click on the Add button.\nExposing the KeyCloak service in Kubernetes. So far we have accessed the keycloak service from the browser by using the port-forwarding and then accessing it via local-port. But for production usage and to configure it as SSO inside ENBUILD we need to expose it on a public IP address.\nThere are multiple ways to achive that -\nExpose the keycloak-http service as LoadBalancer - This way the kubernertes will create a external loadbalancer and expose the service on a public IP address. Create an Ingress resource for the keycloak-http service - This way we can use a ingress controller to route traffic to the keycloak service based on the hostname. If you have istio deployed and configured in your cluster, then expose it as virtual service. This is the sample virtaul service configurations you can use ❗ Note: Make sure to adjust the hosts to the right value to which you want to expose the service.\nCreate a DNS record for the keycloak after you have exposed the keycloak-http service using any of the above methods, you can create a DNS record pointing to the public IP address or FQDN of the loadbalncer.\ne.g. if you have exposed the service using the istio virtual service you will need to create a DNS record for this service in your DNS provider.\nThe IP address of the DNS will be the EXTERNAL-IP of the istio-ingressgateway service, you can find that using the command below.\nkubectl get svc -n istio-system istio-ingressgateway -o jsonpath=\u0026#39;{.status.loadBalancer.ingress[*].ip}\u0026#39; Create a DNS type A record using the IP address from the command above.\nOnce done you can proceed to configure keycloak as SSO for ENBUILD\n","date":"0001-01-01","id":21,"permalink":"/docs/how-to-guides/install-and-configure-keycloak-for-enbuild-sso/","summary":"Install and Configure Keycloak for ENBUILD SSO","tags":[],"title":"Install and Configure Keycloak for ENBUILD SSO"},{"content":"Overview This guide outlines the steps required to create a new catalog template repository in your GitHub or Gitlab account.\nPrerequisites You must have a GitHub and or Gitlab account and have access to the orgnizations you are part of. Familiarity with Git and Github Actions is recommended but not required. Steps Create a new repository\nNavigate to your GitHub dashboard and click on the \u0026lsquo;+\u0026rsquo; button in the top left corner, then select New repository. Enter a name for your catalog template repository initialize it with a README file, and make it public if you want your catalog templates to be publicly available.\nAdd the images and infrastructure files\nAdd the following files to your repository:\nimages/\u0026lt;catalog-name\u0026gt;.png \u0026ndash; This is the image ENBUILD will disaply while showing the catalog in the UI. images/\u0026lt;component-name\u0026gt;.png \u0026ndash; You have to create images for all the compoments for your catalog. This is the image ENBUILD will disaply while showing the component of catalog in the UI. infra/ , all your Terraform infrastructure files should go here scripts/, all your scripts should go here values.yaml \u0026ndash; This file will contain all the default values for your templates. Add the CI-CD Pipeline files\nIf its a GitHub repo:\nCreate a file .github/workflows/main.yml and add the deployment steps to it. Disable the github actions for this repo. Since this is a template repository, you don\u0026rsquo;t want your templates being deployed when someone adds a commit to this repo. If its a Gitlab repo:\nCreate a file gitlab-ci.yml and add the deployment steps to it ⚡ Note: The Gitlab CI expects the CI file name to be .gitlab-ci.yml, but since the repository we are operating on is a template repository and we do not want to run our pipeline locally for this Repository, hence the name of the file is changed to gitlab-ci.yml and ENBUILD will rename this to .gitlab-ci.yml in the target deployment repository of this catalog.\nReference Catalog Repository See the example Github catalog template repository and\nexample Gitlab catalog template repository\nfor an example of what the template repository should look like.\nNext Steps Creating a new catalog entry in ENBUILD ","date":"0001-01-01","id":22,"permalink":"/docs/how-to-guides/creting-new-catalog-template-repository/","summary":"Creting new catalog template repository","tags":[],"title":"Creting new catalog template repository"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nENBUILD is installed and you have admin access to it. You have created the Catalog templates repository for the catalog item (either in Gitlab/Github) If the catalog template repository is private, you have aquired the token with readonly access to the repository. Adding a new repository Navigate to the Repositories tab of the Admin panel and click on Connect New Respository. You will be presented with the following form:\nChoose your VCS: Choose the VCS of your catalog, either Gitlab or Github. In this example, we will use Gitlab.\nSet up Repository Credentials: Enter the repository URL in the Repository URL field.\nIf the repository is private, enter the Username in the Username field and the Token in the Password field.\nClick on Connect check the connection of the repository.\nThere are two ways of adding a new catalog item to ENBUILD:\nAdding a New Catalog Item Manually Adding a New Catalog Item using exported JSON Adding a New Catalog Item Manually. Login to ENBUILD as admin user. Navigate to Manage Catalogs tab and click on Create Catalog. You will be presented with the following form:\nChoose your VCS: Choose the VCS of your catalog, either Gitlab or Github. In this example, we will use Gitlab.\nSet up Catalog Details: Enter a Name for your catalog. This name is displayed to the user while they are browsing the ENBUILD. Choose a Type for your catalog items. The type defines the type of the catalog. Choose the template Repository for your catalog items from the dropdown menu. This is the template repository that you have created in previous step (or) click on the Add new button to add a new repository. If the template repository is private, Check the IsPrivate button and provide the Readonly Access Token in the Token field. Provide the Project ID of the template repository. Enter a Readme File Path this is the path of the README file that you want to disaply when user clicks on your catalog item. Enter a Values Folder Path this is the directory of the Values files for the components. Choose the Branch for your catalog template to be used. (only required in Gitlab) Enter an Image Path of the image to be displayed for a catalog item in ENBUILD UI. Select Multi Select. This feature allows users to select multiple components from same catagary in a catalog. If enabled the user can install/enable multiple components at once. Otherwise a single component is installed/enabled at a time for a component catagory. Click on Save And Continue to proceed to add Components for the Catalogs Set up Component Details Enter a Name for your component. Select a Tool Type for your component item. This is used to group components in a single group. Choose the component Repository for your component items from the repository dropdown (or) click on the Add new button to add a new repository. Ommit if the component and catalog are in same repository. Provide the Project ID of the template repository. Ommit if the component and catalog are in same repository. Choose the Branch as Ref for your component template to be used. (only required in Gitlab) Ommit if the component and catalog are in same repository. Enter a Variable File Path this is the input variable file which ENBUILD will display for the components , and user will use to change the beheviour of the deployment. Enter an Image Path of the image to be displayed for a component item in ENBUILD UI. Select Mandatory. If the Catalog is created enabling the Multi Select . Enabling this Mandatory will set This component to be enabled by default in ENBUILD UI. Click on Save And Continue to proceed to add Infrastrcture for the Catalogs Set up Infrastrcture Details for the catalogs Here you can select all the infrastructure providers that the catalog needs to be installed. For now we support AWS ,Azure Oracle and KUBERNETES You can select 1 or multiple providers for your catalog, but you must have at least one provider selected for the catalog to be valid. And your catalog template should have provision to support all the selected providers.\nAdding the Permission for the catalogs to ENBUILD ROLES Once the Catalog is created , you need to add permissions to the catalog for a particuler role that can have access to this catalog.\nAnd you can provide the permissions to each catalog as per your requirement for each catalog and roles.\nAdding a New Catalog Item using exported JSON The other way of creating the Catalog Item is providing the raw catalog json file that you have exported from ENBUILD or uploading the json file containing the catalog information.\nLogin to ENBUILD as admin user. Navigate to Manage Catalogs tab and click on Create Catalog. and then Choose the VCS of your catalog, either Gitlab or Github. In this example, we will use Gitlab. Click on Upload Json button to to proceed to import the catalog using JSON Here you can provide the raw json of any catalog exported from ENBUILD UI. OR upload a file from your local machine having the catalog json. ","date":"0001-01-01","id":23,"permalink":"/docs/how-to-guides/adding-new-catalog-item-in-enbuild/","summary":"Adding new Catalog Item in ENBUILD","tags":[],"title":"Adding new Catalog Item in ENBUILD"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nKubernetes cluster is up and running and you have access to it via kubectl command. Helm 3 installed on your system. Create Namespace and Image pull secret To install the Nginx Ingress Controller to your cluster, you’ll first need to add its repository to Helm by running:\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx The output will be:\n\u0026#34;ingress-nginx\u0026#34; has been added to your repositories Update your system to let Helm know what it contains:\nhelm repo update ingress-nginx install the Nginx ingress: run the following command to install the Nginx ingress:\nhelm install nginx-ingress ingress-nginx/ingress-nginx --set controller.publishService.enabled=true This command installs the Nginx Ingress Controller from the stable charts repository, names the Helm release nginx-ingress, and sets the publishService parameter to true.\nOnce it has run, you will receive an output similar to this:\nNAME: nginx-ingress LAST DEPLOYED: Wed Apr 10 16:19:24 2024 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The ingress-nginx controller has been installed. It may take a few minutes for the load balancer IP to be available. You can watch the status by running \u0026#39;kubectl get service --namespace default nginx-ingress-ingress-nginx-controller --output wide --watch\u0026#39; An example Ingress that makes use of the controller: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example namespace: foo spec: ingressClassName: nginx rules: - host: www.example.com http: paths: - pathType: Prefix backend: service: name: exampleService port: number: 80 path: / # This section is only required if TLS is to be enabled for the Ingress tls: - hosts: - www.example.com secretName: example-tls If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided: apiVersion: v1 kind: Secret metadata: name: example-tls namespace: foo data: tls.crt: \u0026lt;base64 encoded cert\u0026gt; tls.key: \u0026lt;base64 encoded key\u0026gt; type: kubernetes.io/tls ... Helm has logged what resources it created in Kubernetes as a part of the chart installation.\nOptional - Install CertManager To use TLS with ingress we need to create a certificate with propr TLS data. You can create that manually. But for reference we will use the Cert-manager to manage our certificates.\nHere, we will install CertManager and use self-signed-certificate.\nTo deploy a proper certificate using CertManager refer the official Documentation\nkubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml # kubectl get pods --namespace cert-manager NAME READY STATUS RESTARTS AGE cert-manager-67c98b89c8-g428w 1/1 Running 0 5m12s cert-manager-cainjector-5c5695d979-7qczq 1/1 Running 0 5m12s cert-manager-webhook-7f9f8648b9-2bt85 1/1 Running 0 5m12s Create a self signed cluster issuer\n--- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned-ca-issuer spec: selfSigned: {} --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: selfsigned-ca namespace: cert-manager spec: isCA: true commonName: selfsigned-ca secretName: root-secret privateKey: algorithm: ECDSA size: 256 issuerRef: name: selfsigned-ca-issuer kind: ClusterIssuer group: cert-manager.io --- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned spec: ca: secretName: root-secret --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: self-sign-cert namespace: kube-system spec: secretName: wildcard-cert commonName: ijuned.com dnsNames: - ijuned.com - \u0026#34;*.ijuned.com\u0026#34; issuerRef: name: selfsigned kind: ClusterIssuer --- Apply the configurations\nkubectl apply -f self-sign-cert.yaml Follow the the official Documentation for using cert-manager issuers other than self-sign.\nInstall ENBUILD with exposing service using Ingress To install ENBUILD with exposing frontend serivice using Ingress you can use these example helm input file.\n❗ Note: Make sure to change the domain and the certificate name as per your requirments.\nCreate DNS records Run this command to watch the ingress-ingress-nginx-controller Load Balancer become available:\nkubectl --namespace default get services -o wide -w nginx-ingress-ingress-nginx-controller This command fetches the Nginx Ingress service in the default namespace and outputs its information, but the command does not exit immediately. With the -w argument, it watches and refreshes the output when changes occur.\nWhile waiting for the Load Balancer to become available, you may receive a pending response:\nAfter some time has passed, the IP address of your newly created Load Balancer will appear:\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR nginx-ingress-ingress-nginx-controller LoadBalancer 10.43.254.211 192.168.0.108 80:31730/TCP,443:32755/TCP 5m56s app.kubernetes.io/component=controller,app.kubernetes.io/instance=nginx-ingress,app.kubernetes.io/name=ingress-nginx Next, you’ll need to ensure that your domains like enbuild.ijuned.com and rabbitmq.ijuned.com are pointed to the Load Balancer via A records. This is done through your DNS provider. To configure your DNS records follow your DNS provider documentaion.\nYou’ve installed the Nginx Ingress maintained by the Kubernetes community. It will route HTTP and HTTPS traffic from the Load Balancer to appropriate back-end Services configured in the Ingress Resources.\nOnce the DNS / Host entry is added you can access the ENBUILD using the created ingress domain\n❯ kubectl get ing -n enbuild NAME CLASS HOSTS ADDRESS PORTS AGE enbuild-enbuild-ing nginx enbuild.ijuned.com 192.168.0.108 80, 443 10m ","date":"0001-01-01","id":24,"permalink":"/docs/how-to-guides/installing-nginx-ingress/","summary":"Steps to Install Nginx Ingress","tags":[],"title":"Installing Nginx Ingress"},{"content":"You can export a catalog item from ENBUILD in JSON format. You can use this JSON to commit in the version control system for a backup. And then use this json to import to another ENBUILD instance.\nLogin to ENBUILD as admin user. Navigate to Manage Catalogs tab and you will see the list of all active catalogs in the ENBUILD instance. Select the Catalog that you want to export and then at the Actions coloumn select the export icon. ","date":"0001-01-01","id":25,"permalink":"/docs/how-to-guides/exporting-catalog-item-from-enbuild/","summary":"Exporting Catalog Item from ENBUILD","tags":[],"title":"Exporting Catalog Item from ENBUILD"},{"content":"This cheat sheet provides commonly used kubectl commands for managing Kubernetes clusters.\nBasic Commands List all pods kubectl get pods List all pods in a specific namespace kubectl get pods -n \u0026lt;namespace\u0026gt; List all nodes kubectl get nodes List all services kubectl get services How to check logs of the pods kubectl logs \u0026lt;pod-name\u0026gt; How to check logs of the pods in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; How to check logs of the pods in a specific container in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container in a specific namespace with timestamps kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps How to check logs of the pods in a specific container in a specific namespace with timestamps and limit the output to 10 lines kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps --tail 10 ","date":"0001-01-01","id":26,"permalink":"/docs/troubleshooting/kubectl-cheat-sheet/","summary":"This cheat sheet provides commonly used kubectl commands for managing Kubernetes clusters.\nBasic Commands List all pods kubectl get pods List all pods in a specific namespace kubectl get pods -n \u0026lt;namespace\u0026gt; List all nodes kubectl get nodes List all services kubectl get services How to check logs of the pods kubectl logs \u0026lt;pod-name\u0026gt; How to check logs of the pods in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; How to check logs of the pods in a specific container in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container in a specific namespace with timestamps kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps How to check logs of the pods in a specific container in a specific namespace with timestamps and limit the output to 10 lines kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps --tail 10 ","tags":[],"title":"Kubectl Cheat Sheet"},{"content":" About Q: Who is behind this project?\nA: VivSoft! 🐘 VivSoft is focused on solving complex problems in the public sector using innovative technologies. VivSoft is working with business leaders in federal, state and local government to help mission owners accelerate innovation using DevSecOps, Cloud, AI/ML and Blockchain Technologies.\nQ: What problem does ENBUILD solve?\nA: ENBUILD\u0026rsquo;s goal is to empower organizations to leverage Kubernetes and cloud-native technologies effectively while minimizing the complexity and overhead associated with deployment and management tasks. By offering pre-configured catalog items and promoting best practices, ENBUILD enables organizations to streamline their development workflows, reduce time to market, and achieve their product development goals more efficiently.\nCosts and Licensing Fees Q: Is ENBUILD free to use?\nA: Yes, ENBUILD is free to use.\nQ: What license does ENBUILD use?\nA: ENBUILD utilizes the Apache License, which is an open-source software license recognized for its flexibility and permissive nature. This license allows users to freely use, modify, and distribute the software, whether for personal, commercial, or open-source projects. For more detailed information about the Apache License and its implications, please refer to the official Apache Software Foundation website or consult the license file included with the ENBUILD software distribution.\nSecurity Q: What dependencies does ENBUILD have?\nA: ENBUILD, being a Kubernetes native application, relies on certain dependencies to function optimally. These dependencies include:\nKubernetes Cluster: ENBUILD requires a Kubernetes cluster to operate. This ensures that ENBUILD can leverage the scalability, resilience, and orchestration capabilities provided by Kubernetes, thereby enabling efficient deployment and management of containerized applications. Version Control System (VCS) for ENBUILD Catalog Item Deployments: ENBUILD utilizes a Version Control System for managing and deploying ENBUILD Catalog Items. Currently, ENBUILD supports integration with two popular VCS platforms:\nGitLab: ENBUILD seamlessly integrates with GitLab, allowing users to leverage the robust features of GitLab for managing and versioning their ENBUILD Catalog Items. This includes support for both the Software as a Service (SaaS) offering of GitLab and self-hosted deployments of GitLab instances.\nGitHub: ENBUILD also supports integration with GitHub, enabling users to utilize GitHub\u0026rsquo;s collaborative features and version control capabilities for ENBUILD Catalog Item deployments. Similar to GitLab, ENBUILD supports both the SaaS offering of GitHub and self-hosted deployments of GitHub Enterprise instances.\nBy supporting these Version Control Systems, ENBUILD provides users with flexibility and choice, allowing them to seamlessly integrate ENBUILD into their existing development workflows while leveraging the capabilities of their preferred VCS platform.\nFor further details on setting up ENBUILD dependencies and integration with specific Version Control Systems, please refer to the ENBUILD documentation or reach out to our support team for assistance.\nDeployment Q: What types of Kubernetes distributions is ENBUILD compatible with?\nA: ENBUILD has been deployed and tested on the following distributions of Kubernetes:\nAmazon EKS (Elastic Kubernetes Service): ENBUILD is fully compatible with Amazon EKS, allowing users to deploy and manage ENBUILD on Amazon Web Services\u0026rsquo; managed Kubernetes service. Azure AKS (Azure Kubernetes Service): ENBUILD seamlessly integrates with Azure AKS, enabling users to deploy and run ENBUILD on Microsoft Azure\u0026rsquo;s managed Kubernetes service. Rancher K3D: ENBUILD supports deployment on Rancher K3D, a lightweight Kubernetes distribution designed for local development and testing purposes. Rancher RKE2: ENBUILD is compatible with Rancher RKE2, an enterprise-grade Kubernetes distribution optimized for production workloads. Configuration Q: What is an ENBUILD Catalog Item (CI)?\nA: An ENBUILD Catalog Item, often abbreviated as CI, serves as a standardized template project designed to streamline the deployment and management of various infrastructure components and applications within the ENBUILD ecosystem. These Catalog Items are meticulously crafted by developers to encapsulate pre-configured settings, best practices, and reusable components, providing users with a simplified and consistent approach to deploying complex infrastructure and applications.\nENBUILD Catalog Items are tailored to support a diverse range of use cases and technologies, including:\nTerraform Infrastructure as Code (IaC): Catalog Items for Terraform enable users to define and manage cloud infrastructure resources using Infrastructure as Code principles. These Catalog Items offer pre-defined templates and configurations for provisioning resources on popular cloud platforms such as AWS, Azure, and Google Cloud Platform, facilitating rapid deployment and automation of infrastructure provisioning tasks.\nKubernetes Distributions (e.g., Amazon EKS, Azure AKS): Catalog Items for Kubernetes distributions provide users with pre-configured templates for deploying and managing Kubernetes clusters on various cloud providers, such as Amazon EKS (Elastic Kubernetes Service) and Azure AKS (Azure Kubernetes Service). These Catalog Items simplify the setup and configuration of Kubernetes clusters, enabling users to leverage the scalability and agility of Kubernetes for containerized application deployment and orchestration.\nHelm Deployments (e.g., Big Bang): Catalog Items for Helm deployments offer pre-packaged configurations and charts for deploying applications and services using Helm, a popular package manager for Kubernetes. These Catalog Items streamline the deployment of complex applications by providing ready-to-use Helm charts and configurations, reducing the time and effort required for setting up and configuring application environments.\nBy leveraging ENBUILD Catalog Items, developers gain access to a curated library of templates and configurations that serve as starting points for their projects. These Catalog Items not only accelerate the development and deployment process but also promote consistency, reliability, and best practices across projects within the ENBUILD ecosystem.\nQ: What is an Version Control System (VCS)?\nA: A Version Control System (VCS) is a fundamental tool used in software development to manage and track changes to source code, configuration files, and other project assets over time. It allows multiple developers to collaborate on a project concurrently while maintaining a history of all modifications made to the project files.\nIn the context of ENBUILD, a Version Control System (VCS) plays a crucial role in managing and deploying ENBUILD Catalog Items, which are template projects designed to facilitate the deployment of infrastructure components and applications within the ENBUILD ecosystem. ENBUILD supports integration with popular VCS platforms such as GitLab and GitHub, providing users with the flexibility to version control their Catalog Items and streamline the deployment process.\nKey features and benefits of using a Version Control System (VCS) include:\nHistory Tracking: VCS systems maintain a detailed history of changes made to project files, including who made the changes and when they were made. This allows developers to review past revisions, track the evolution of the project, and revert to previous versions if necessary.\nCollaboration: VCS systems enable seamless collaboration among team members by providing mechanisms for sharing and synchronizing changes to project files. Multiple developers can work on the same codebase simultaneously without risking conflicts or data loss.\nBranching and Merging: VCS systems support branching and merging workflows, allowing developers to create separate branches to work on specific features or fixes independently. Branches can later be merged back into the main codebase, ensuring a streamlined and organized development process.\nAuditing and Compliance: VCS systems offer auditing capabilities that help maintain compliance with regulatory requirements and internal policies. Organizations can track and monitor all changes made to project files, ensuring accountability and transparency in the development process.\nBy leveraging a Version Control System (VCS) such as GitLab or GitHub, ENBUILD users can effectively manage their Catalog Items, collaborate with team members, track changes, and maintain a consistent and reliable deployment workflow.\nChange Control Q: What is the Release schedule?\nA: To Be Determined. 📆\n","date":"0001-01-01","id":27,"permalink":"/docs/faq/frequently-asked-questions/","summary":"About Q: Who is behind this project?\nA: VivSoft! 🐘 VivSoft is focused on solving complex problems in the public sector using innovative technologies.","tags":[],"title":"Frequently Asked Questions"},{"content":"Glossary of terms\nTerm Definition DevSecOps This is a combination of development, security, and operations. Imagine a team working on creating a software, where everyone from programmers to security experts and IT professionals collaborate closely from the start to the end of a project. This approach ensures that the software is developed quickly, securely, and efficiently. Containerization Think of this as packing your entire software, with everything it needs to run (like code, libraries, and system tools), into a single package or \u0026lsquo;container\u0026rsquo;. This container can then be easily moved and run on different computers or servers, much like how you might pack your belongings into a suitcase when traveling, ensuring you have everything you need wherever you go. Kubernetes This is like a conductor for an orchestra, but instead of managing musical instruments, it manages containers (those packages mentioned earlier). Kubernetes helps in organizing and automating the deployment, scaling (adjusting the size or capacity), and management of containerized applications, ensuring they run smoothly and efficiently. Helm Deployments Helm is akin to a package manager for Kubernetes. Just as you might use a tool on your computer to install, update, or manage software, Helm does this for Kubernetes applications. It works with packages called \u0026lsquo;charts\u0026rsquo;, which are collections of information necessary to create a standardized deployment on Kubernetes. This makes installing and managing Kubernetes applications as easy as installing apps on your smartphone. Terraform Infrastructure Deployments Terraform is a tool that allows you to describe your infrastructure (like servers, databases, and networks) using code. This approach lets you set up and manage your infrastructure through code files, which can be versioned, reused, and shared. Imagine building a model city where you can design and rearrange buildings, roads, and parks with a few clicks. Terraform does something similar for computer infrastructure, allowing for easy adjustments and replication across different environments. GitLab and GitHub Integration GitLab and GitHub are platforms that allow developers to store their code, track changes, and collaborate with others. Integrating with these platforms means ENBUILD can automatically interact with your code stored on GitLab or GitHub, helping automate parts of the development process like testing and deployment, much like how social media apps can share information to keep everything in sync. CI/CD (Continuous Integration/Continuous Deployment) This is a practice in software development where every time a developer makes changes to the code (continuous integration), those changes are automatically tested and then deployed to the live application (continuous deployment). It\u0026rsquo;s like a factory assembly line for software, where new features are added, tested, and made available to users seamlessly and efficiently. NoSQL Database Unlike traditional databases that store data in tables, a NoSQL database uses a more flexible format (like key-value pairs, documents, or graphs). This flexibility allows for easier storage and retrieval of data in various formats, making it suitable for applications that handle diverse and large amounts of data, such as social networks or e-commerce sites. Helm Chart A Helm chart is a package containing all the necessary information to run an application or service on Kubernetes. It includes details on how the application should be configured and deployed, similar to a recipe that outlines the ingredients and steps needed to make a dish. RBAC (Role-Based Access Control) RBAC is a method for restricting system access to authorized users. It\u0026rsquo;s like having different keys for different rooms in a building; depending on your role (e.g., manager, employee), you\u0026rsquo;re given keys (access) only to the areas you need to perform your job. Iron Bank Accredited Containers Iron Bank refers to a repository of secure container images that have been approved for use within certain secure environments, such as government or military. Think of it as a library of vetted, safe-to-use building blocks for software that meet high security standards. GitOps This is a way to manage your infrastructure and applications by using Git (a version control system) as the single source of truth. It\u0026rsquo;s like maintaining a detailed blueprint for a machine; any changes to the blueprint automatically update the machine, ensuring it always matches the design specifications. KubeFlow KubeFlow is a project aimed at making deployments of machine learning (ML) workflows on Kubernetes simple, portable, and scalable. Imagine if you could set up a complex scientific experiment with all its equipment and processes in a box, move it anywhere, and have it work the same way every time—that\u0026rsquo;s what KubeFlow does for ML projects. Landing Zones In cloud computing, a landing zone is a predefined environment with a set of policies, tools, and computing resources. It\u0026rsquo;s prepared ground for new applications or services, ensuring they have a secure and efficient place to operate from the moment they\u0026rsquo;re deployed. Service Mesh A service mesh is a layer that controls how different parts of an application share data with one another. It\u0026rsquo;s like a sophisticated system within a busy city that manages how cars (data) navigate the streets (network) to ensure smooth traffic flow and delivery of passengers (services) to their destinations safely and efficiently. ","date":"0001-01-01","id":28,"permalink":"/docs/faq/glossary/","summary":"Glossary of terms\nTerm Definition DevSecOps This is a combination of development, security, and operations. Imagine a team working on creating a software, where everyone from programmers to security experts and IT professionals collaborate closely from the start to the end of a project.","tags":[],"title":"Glossary"},{"content":" ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, revolutionizes the application deployment process. At its essence, ArgoCD enables organizations to manage and automate the deployment of applications through Git repositories, promoting a declarative approach to configuration and versioning. It continuously monitors the desired state of applications defined in Git and automatically reconciles any divergences with the current state in the Kubernetes cluster. This ensures that applications are consistently deployed and maintained across different environments. ArgoCD\u0026rsquo;s intuitive user interface provides visibility into the deployment status, allowing for easy tracking and rollbacks. With support for multiple clusters and repositories, ArgoCD empowers teams to achieve efficient, scalable, and auditable continuous delivery workflows in Kubernetes environments.\nSample ArgoCD Commands Below is a list of common ArgoCD CLI commands for managing Kubernetes applications:\nLogging in to Argo CD Server To log in to the Argo CD server, use the following command:\nargocd login \u0026lt;argocd-server-url\u0026gt; --username \u0026lt;username\u0026gt; --password \u0026lt;password\u0026gt; Setting the Current Context Before executing any Argo CD CLI commands, you need to set the current context to the Argo CD server:\nargocd context \u0026lt;argocd-server-url\u0026gt; Listing Applications List all applications managed by Argo CD:\nargocd app list Getting Information about an Application Retrieve detailed information about a specific application:\nargocd app get \u0026lt;application-name\u0026gt; Syncing an Application Manually sync an application with its target state:\nargocd app sync \u0026lt;application-name\u0026gt; Setting Sync Options You can set various sync options for an application. For example:\nargocd app set \u0026lt;application-name\u0026gt; --sync-policy \u0026lt;policy\u0026gt; Deleting an Application Delete an application from Argo CD:\nargocd app delete \u0026lt;application-name\u0026gt; Configuring Auto-Sync Enable or disable auto-sync for an application:\nargocd app auto-sync \u0026lt;application-name\u0026gt; --\u0026lt;enable/disable\u0026gt; Viewing Application Resources List Kubernetes resources managed by an application:\nargocd app resources \u0026lt;application-name\u0026gt; Accessing Argo CD Web UI You can also access the Argo CD Web UI by running:\nargocd open Logging out of Argo CD Server To log out of the Argo CD server, run:\nargocd logout Further Reading Read argocd Official Documentation ","date":"0001-01-01","id":29,"permalink":"/docs/references/argocd/","summary":"ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, revolutionizes the application deployment process. At its essence, ArgoCD enables organizations to manage and automate the deployment of applications through Git repositories, promoting a declarative approach to configuration and versioning.","tags":[],"title":"ArgoCD"},{"content":" Big Bang is a declarative, continuous delivery tool for deploying DoD hardened and approved packages into a Kubernetes cluster.\nUsage \u0026amp; Scope Big Bang\u0026rsquo;s scope is to provide publicly available installation manifests for packages required to adhere to the DoD DevSecOps Reference Architecture and additional useful utilities. Big Bang packages are broken into three categories:\nCore: Core packages are a group of capabilities required by the DoD DevSecOps Reference Architecture, that are supported directly by the Big Bang development team. The specific capabilities that are considered core currently are Service Mesh, Policy Enforcement, Logging, Monitoring, and Runtime Security.\nAddons: Addon packages are any packages/capabilities that the Big Bang development team directly supports that do not fall under the above core definition. These serve to extend the functionality/features of Big Bang.\nCommunity: Community packages are any packages that are maintained by the broader Big Bang community (users, vendors, etc). These packages could be alternatives to core or addon packages, or even entirely new packages to help extend usage/functionality of Big Bang.\nIn order for an installation of Big Bang to be a valid installation/configuration you must install/deploy a core package of each category (for additional details on categories and options see here).\nBig Bang also builds tooling around the testing and validation of Big Bang packages. These tools are provided as-is, without support.\nBig Bang is intended to be used for deploying and maintaining a DoD hardened and approved set of packages into a Kubernetes cluster. Deployment and configuration of ingress/egress, load balancing, policy auditing, logging, monitoring, etc. are handled via Big Bang. Additional packages (e.g. ArgoCD, GitLab) can also be enabled and customized to extend Big Bang\u0026rsquo;s baseline. Once deployed, the Kubernetes cluster can be used to add mission specific applications.\nFurther Reading Read big bang Official Documentation Checkout big bang on GitHub ","date":"0001-01-01","id":30,"permalink":"/docs/references/platform-one-big-bang/","summary":"Big Bang is a declarative, continuous delivery tool for deploying DoD hardened and approved packages into a Kubernetes cluster.","tags":[],"title":"Platform One Big Bang"},{"content":" GitLab stands as a comprehensive DevOps platform, providing end-to-end solutions for source code management, continuous integration, delivery, security, and more. As an integrated tool, GitLab facilitates collaboration among development, operations, and security teams, streamlining the entire software development lifecycle. With its version control capabilities based on Git, GitLab allows teams to efficiently manage and track changes in their codebase. Beyond version control, GitLab\u0026rsquo;s robust CI/CD pipelines automate the building, testing, and deployment of applications, ensuring rapid and reliable delivery. The platform also emphasizes security with built-in features for code scanning, vulnerability management, and compliance tracking. GitLab\u0026rsquo;s all-in-one approach fosters collaboration, transparency, and efficiency, making it a preferred choice for organizations aiming to achieve seamless and integrated DevOps workflows.\nFurther Reading Read gitlab Official Documentation ","date":"0001-01-01","id":31,"permalink":"/docs/references/gitlab/","summary":"GitLab stands as a comprehensive DevOps platform, providing end-to-end solutions for source code management, continuous integration, delivery, security, and more.","tags":[],"title":"GitLab"},{"content":" The Helm CLI serves as a powerful package manager for Kubernetes applications, streamlining and simplifying the deployment and management of complex containerized applications. At its core, Helm utilizes charts—pre-configured packages of Kubernetes resources—to encapsulate and version entire applications. With the Helm CLI, users can effortlessly install, upgrade, and roll back applications, ensuring consistent and reproducible deployments across different environments. Its templating system allows for easy customization of configurations, while the Helm repository facilitates the sharing and distribution of charts. Whether orchestrating microservices or deploying scalable applications, Helm proves to be an indispensable tool for developers and operators seeking efficiency and consistency in Kubernetes environments. Sample Helm Commands Below is a list of common Helm CLI commands for managing Kubernetes applications:\nInitializing Helm Initialize Helm in your Kubernetes cluster:\nhelm init Adding a Helm Repository Add a repository containing Helm Charts:\nhelm repo add stable https://charts.helm.sh/stable Searching for Helm Charts Searching for Helm charts in the added repositories:\nhelm search repo \u0026lt;keyword\u0026gt; Installing a Helm Chart Install a Helm chart into your Kubernetes cluster:\nhelm install \u0026lt;release-name\u0026gt; \u0026lt;chart-name\u0026gt; Listing Installed Helm Releases List all installed Helm releases:\nhelm list Getting Information about a Release Get information about a specific Helm release:\nhelm status \u0026lt;release-name\u0026gt; Upgrading a Helm Release Upgrade a Helm release to a new version:\nhelm upgrade \u0026lt;release-name\u0026gt; \u0026lt;chart-name\u0026gt; Deleting a Helm Release Delete a Helm release from your Kubernetes cluster:\nhelm delete \u0026lt;release-name\u0026gt; Viewing Helm Release History View the history of changes for a Helm release:\nhelm history \u0026lt;release-name\u0026gt; Uninstalling Helm To uninstall Helm from your Kubernetes cluster, run:\nhelm reset Further Reading Read helm Official Documentation ","date":"0001-01-01","id":32,"permalink":"/docs/references/helm/","summary":"The Helm CLI serves as a powerful package manager for Kubernetes applications, streamlining and simplifying the deployment and management of complex containerized applications.","tags":[],"title":"Helm"},{"content":" Istio, a robust and open-source service mesh platform, redefines how microservices communicate within a Kubernetes environment. Acting as a dedicated layer for managing and securing microservice interactions, Istio provides a comprehensive set of tools for traffic management, load balancing, and observability. By intelligently routing and controlling the flow of traffic between services, Istio enhances resilience, fault tolerance, and overall service reliability. Its built-in security features, such as mutual TLS authentication and access control, fortify communication channels between microservices. Additionally, Istio\u0026rsquo;s observability capabilities, including distributed tracing and metrics collection, offer insights into application performance. With Istio, organizations can effortlessly implement a resilient and secure microservices architecture, ultimately improving the manageability and reliability of their containerized applications. Sample Istio Commands Below is a list of common Istio CLI commands for managing Istio service mesh:\nInstalling Istio Install Istio into your Kubernetes cluster:\nistioctl install Verifying Istio Installation Verify that Istio components are installed correctly:\nistioctl verify-install Listing Istio Virtual Services List all Istio Virtual Services in the cluster:\nistioctl get virtualservices Creating a Virtual Service Create a new Istio Virtual Service:\nistioctl create -f virtual-service.yaml Updating a Virtual Service Update an existing Istio Virtual Service:\nistioctl replace -f virtual-service.yaml Deleting a Virtual Service Delete an Istio Virtual Service:\nistioctl delete virtualservice \u0026lt;virtual-service-name\u0026gt; Listing Istio Gateways List all Istio Gateways in the cluster:\nistioctl get gateways Viewing Istio Service Mesh Dashboard Access the Istio Service Mesh dashboard:\nistioctl dashboard kiali Generating Istio Service Graph Generate a service graph for Istio services:\nistioctl analyze Viewing Istio Proxy Logs View logs from Istio proxies:\nistioctl proxy-config log \u0026lt;pod-name\u0026gt; Upgrading Istio Upgrade Istio to a newer version:\nistioctl upgrade -f istio-upgrade.yaml Uninstalling Istio Uninstall Istio from your Kubernetes cluster:\nistioctl x uninstall --purge Further Reading Read istio Official Documentation ","date":"0001-01-01","id":33,"permalink":"/docs/references/istio/","summary":"Istio, a robust and open-source service mesh platform, redefines how microservices communicate within a Kubernetes environment. Acting as a dedicated layer for managing and securing microservice interactions, Istio provides a comprehensive set of tools for traffic management, load balancing, and observability.","tags":[],"title":"Istio"},{"content":" K3D, a lightweight and versatile tool, simplifies the management and deployment of Kubernetes clusters by bringing the power of Kubernetes into a single-node environment. Designed for simplicity and speed, K3D allows developers and operators to spin up Kubernetes clusters with ease, making it an ideal choice for local development, testing, and CI/CD pipelines. Leveraging containerd and other containerization technologies, K3D offers a minimalistic yet efficient Kubernetes experience. Users can create, scale, and delete clusters effortlessly, making it a valuable tool for scenarios where resource constraints or rapid cluster provisioning are crucial. With K3D, developers can focus on building and testing applications in a Kubernetes-like environment without the complexity of managing large-scale clusters, thereby accelerating the development lifecycle.\nSample K3D Commands Below is a list of basic K3D CLI commands for managing Kubernetes clusters:\nCreating a Kubernetes Cluster Create a new Kubernetes cluster using k3d:\nk3d cluster create \u0026lt;cluster-name\u0026gt; Listing Kubernetes Clusters List all existing Kubernetes clusters managed by k3d:\nk3d cluster list Getting Information about a Cluster Retrieve detailed information about a specific Kubernetes cluster:\nk3d cluster get \u0026lt;cluster-name\u0026gt; Accessing Kubernetes Cluster Set the kubeconfig context to the newly created Kubernetes cluster:\nexport KUBECONFIG=\u0026#34;$(k3d kubeconfig write \u0026lt;cluster-name\u0026gt;)\u0026#34; Deleting a Kubernetes Cluster Delete a Kubernetes cluster managed by k3d:\nk3d cluster delete \u0026lt;cluster-name\u0026gt; Starting a Kubernetes Cluster Start a previously stopped Kubernetes cluster:\nk3d cluster start \u0026lt;cluster-name\u0026gt; Stopping a Kubernetes Cluster Stop a running Kubernetes cluster:\nk3d cluster stop \u0026lt;cluster-name\u0026gt; Scaling Nodes Scale the number of worker nodes in the cluster:\nk3d node create \u0026lt;node-name\u0026gt; --replicas \u0026lt;num-replicas\u0026gt; Exporting kubeconfig Export the kubeconfig file for a cluster:\nk3d kubeconfig write \u0026lt;cluster-name\u0026gt; Further Reading Read k3d Official Documentation ","date":"0001-01-01","id":34,"permalink":"/docs/references/k3d/","summary":"K3D, a lightweight and versatile tool, simplifies the management and deployment of Kubernetes clusters by bringing the power of Kubernetes into a single-node environment.","tags":[],"title":"K3D"},{"content":"","date":"2023-09-07","id":35,"permalink":"/","summary":"","tags":[],"title":"ENBUILD"},{"content":"","date":"2023-09-07","id":36,"permalink":"/docs/","summary":"","tags":[],"title":"Docs"},{"content":"","date":"0001-01-01","id":37,"permalink":"/categories/","summary":"","tags":[],"title":"Categories"},{"content":"","date":"0001-01-01","id":38,"permalink":"/contributors/","summary":"","tags":[],"title":"Contributors"},{"content":"","date":"0001-01-01","id":39,"permalink":"/tags/","summary":"","tags":[],"title":"Tags"}] \ No newline at end of file +[{"content":"","date":"2023-09-07","id":0,"permalink":"/docs/getting-started/","summary":"","tags":[],"title":"Getting Started"},{"content":"","date":"0001-01-01","id":1,"permalink":"/docs/how-to-guides/","summary":"","tags":[],"title":"How-to Guides"},{"content":"","date":"2023-09-07","id":2,"permalink":"/docs/troubleshooting/","summary":"","tags":[],"title":"Troubleshooting"},{"content":"Test ","date":"2023-09-07","id":3,"permalink":"/docs/faq/","summary":"Test ","tags":[],"title":"FAQ"},{"content":"","date":"2023-09-07","id":4,"permalink":"/docs/references/","summary":"","tags":[],"title":"References"},{"content":"Overview ENBUILD is a cutting-edge software development and engineering tool designed to simplify the complexities of modern-day DevSecOps, containerization and cloud tooling. At its core, ENBUILD offers a self-service catalog featuring pre-packaged templates known as ENBUILD Catalog Items. These templates encompass Terraform Infrastructure deployments on major cloud platforms (AWS, Azure, GCP) and Helm Deployments onto Kubernetes, providing developers with a robust foundation for both infrastructure and application deployment. With automated GitLab and GitHub workflows and pipelines, ENBUILD streamlines the deployment process, allowing developers to focus on value-added work.\nThis tool is specifically tailored for the United States Department of Defense and Government Organizations embarking on DevSecOps Transformation, Cloud Migration, or Platform Development journeys. ENBUILD serves as a strategic accelerator for the adoption of the United States Air Force\u0026rsquo;s Platform One Big Bang Tech Stack, enabling rapid and secure software development and deployment. With seamless integration into popular Continuous Integration / Continuous Deployment engines like GitLab and GitHub, ENBUILD ensures a unified development lifecycle. Moreover, its integration with identity and access management solutions, including Keycloak and Okta, ensures compliance with government regulations through robust Role-Based Access Control (RBAC).\nAs a Kubernetes-native deployment, ENBUILD provides versatility across various Kubernetes environments, supporting AWS EKS, Azure AKS, Rancher, OpenShift, and more. By abstracting toil work and complexities, ENBUILD aims to meet 60-70% of developers\u0026rsquo; needs out of the box, offering a solid starting point for customization and specialization. In summary, ENBUILD stands as a comprehensive solution, empowering organizations to enhance their development processes, accelerate cloud adoption, and navigate the challenges of modern software engineering and infrastructure deployment with ease.\n","date":"2023-09-07","id":5,"permalink":"/docs/getting-started/introduction/","summary":"Overview ENBUILD is a cutting-edge software development and engineering tool designed to simplify the complexities of modern-day DevSecOps, containerization and cloud tooling.","tags":[],"title":"Introduction"},{"content":"\nENBUILD addresses the challenges associated with Day 1 installation and configuration of a Big Bang Kubernetes cluster, offering a streamlined approach for Day 2 operations, including platform upgrades and automation tool patches.\nEase of Use: ENBUILD simplifies Big Bang deployments through a user-friendly UI that facilitates the selection and configuration of DevSecOps pipeline tools. It alleviates common pain points, such as secrets creation and Helm configurations, by utilizing pre-created templates.\nFaster Deployment and Continuous ATO: ENBUILD significantly reduces deployment times, enabling organizations to deploy Big Bang in days rather than weeks or months. It expedites approval processes by leveraging Iron Bank accredited containers.\nOn-Premise \u0026amp; Multi-Cloud Support: ENBUILD provides flexibility by supporting on-premise and cloud deployments across various environments, from edge to commercial Clouds, government Clouds, and air-gapped environments. It allows the deployment of Big Bang stacks on AWS and Azure GovCloud, showcasing cloud-agnostic components.\nOut of the Box Security: Built on pre-hardened DISA compliant containers from Iron Bank, ENBUILD ensures robust security. It incorporates built-in GitOps and Secrets Management for enterprise-grade deployments.\nPre-Built Catalog of Solutions: ENBUILD offers a pre-built catalog featuring solutions for AI/ML deployments using KubeFlow, secure Cloud Computing Architecture based Landing Zones, and data ingestion stacks using Nifi/Kafka/Spark.\nNo Vendor Lock-in: ENBUILD serves as a service delivery accelerator without licensing fees, promoting cost efficiency. It relies on open-source components, fostering a vendor-agnostic approach for greater flexibility and adaptability.\n","date":"2023-09-07","id":6,"permalink":"/docs/getting-started/why-enbuild/","summary":"ENBUILD addresses the challenges associated with Day 1 installation and configuration of a Big Bang Kubernetes cluster, offering a streamlined approach for Day 2 operations, including platform upgrades and automation tool patches.","tags":[],"title":"Why ENBUILD"},{"content":"\nVivSoft is a diverse team of strategists, engineers, designers, and builders\nWHAT WE DO We solve complex organizational challenges, balancing cutting-edge technology with a deep sense of empathy and understanding. We build secure Software Factories based on DoD reference designs and NIST guidelines for Cloud and DevSecOps. These factories deliver AI/ML Applications, Data Science Platforms, Blockchain and Microservices for DoD, Healthcare and Civilian Agencies. ","date":"0001-01-01","id":7,"permalink":"/docs/getting-started/about-vivsoft/","summary":"VivSoft is a diverse team of strategists, engineers, designers, and builders\nWHAT WE DO We solve complex organizational challenges, balancing cutting-edge technology with a deep sense of empathy and understanding.","tags":[],"title":"About Vivsoft"},{"content":"ENBUILD operates as a bridge between developers and the Continuous Integration/Continuous Deployment (CI/CD) systems, specifically with popular platforms like GitHub and GitLab. This tool simplifies the entire software development process, making it accessible and efficient for users with various technical backgrounds.\nGitHub Integration When working with GitHub, ENBUILD seamlessly communicates with the CI/CD provider through REST and GraphQL APIs. It starts by creating a Repository Project, essentially a structured workspace, using a template repository project. The user interacts with ENBUILD through an intuitive user interface (UI), providing inputs that guide the customization of files. These files are then updated based on the user\u0026rsquo;s preferences. Once the configuration is complete, ENBUILD executes the predefined workflow or pipeline, automating the deployment process without the need for intricate manual steps.\nGitLab Integration Similarly, when integrating with GitLab, ENBUILD initiates the process by creating a Repository Project within the GitLab environment. Just like with GitHub, the user\u0026rsquo;s inputs through the ENBUILD UI guide the customization of files within the project. ENBUILD updates these files accordingly, ensuring that the project aligns with the user\u0026rsquo;s specifications. Subsequently, the tool triggers the execution of the workflow or pipeline, seamlessly automating the development and deployment steps.\nIn essence, ENBUILD acts as a facilitator, taking the complexities out of setting up projects and workflows. It empowers users to customize their development environments through a straightforward UI, enabling a smooth and efficient interaction with CI/CD systems like GitHub and GitLab. The result is an accelerated and simplified software development process, allowing developers to focus on building innovative solutions without getting bogged down by technical intricacies.\n","date":"2023-09-07","id":8,"permalink":"/docs/getting-started/how-enbuild-works/","summary":"ENBUILD operates as a bridge between developers and the Continuous Integration/Continuous Deployment (CI/CD) systems, specifically with popular platforms like GitHub and GitLab.","tags":[],"title":"How ENBUILD works"},{"content":"Architecture Digram Frontend Service The ENBUILD frontend service provides the ENBUILD User Interface (UI) to the end user.\nBackend Service The ENBUILD backend service is responsible for integration with the CI/CD Provider.\nUser Service The ENBUILD user service manages the end-user\u0026rsquo;s state, such as authentication, access, API access and role-based access control.\nML Service The ENBUILD ML (Machine Learning) service enables data scientists to quickly create feature sets and deploy models. An instance of Jupyter Notebook can also be created and accessed from this service. (This is a placeholder service for demo purposes for now and will be implemented in the future)\nRequest Service The ENBUILD Request service is demo service to enable linking multiple catalog items to one another and deploy them together. (This is a placeholder service for demo purposes for now and will be implemented in the future)\nRabbitMQ Consumer Service The ENBUILD RabbitMQ consumer service processes jobs in the work queue as well as integrates with the CI/CD Provider APIs.\nNoSQL Database ENBUILD utilizes a NoSQL database to manage the application’s state across all microservices. ENBUILD provides a MongoDB instance out-of-the-box, but also can integrate with Cloud Service Provider NoSQL Databases such as Azure’s CosmosDB and AWS’ DocumentDB.\nIdentity and Access Management ENBUILD supports integration with Okta and Keycloak. Keycloak can act as an Identity Broker for other IdAM products such as Active Directory.\n","date":"2023-09-07","id":9,"permalink":"/docs/getting-started/enbuild-architecture/","summary":"Architecture Digram Frontend Service The ENBUILD frontend service provides the ENBUILD User Interface (UI) to the end user.\nBackend Service The ENBUILD backend service is responsible for integration with the CI/CD Provider.","tags":[],"title":"ENBUILD Architecture"},{"content":"Home Page / Catalogs page Stack List Page Manage Catalog page This page needs admin permission\nBuild ML This page is only visible if the Build ML flag is enabled in the feature flag.\nBuild GenAI This page is only visible if the Build GenAI flag is enabled in the feature flag.\nOperations This page is only visible if the operations flag is enabled in the feature flag.\nMetrics These are the quick metrices Logs These are the logs for your cluster where enbuild is deployed. View Deployment Logs Click on a deployment to view its logs. Create a new deployment Create a new deployment by clicking on the \u0026ldquo;New Deployment\u0026rdquo; button. Settings This page allows you to configure various settings for ENBUILD. ","date":"0001-01-01","id":10,"permalink":"/docs/getting-started/enbuild-ui-walkthrough/","summary":"Home Page / Catalogs page Stack List Page Manage Catalog page This page needs admin permission\nBuild ML This page is only visible if the Build ML flag is enabled in the feature flag.","tags":[],"title":"ENBUILD UI walkthrough"},{"content":"ENBUILD Helm Chart Values The following key value pairs are used to configure ENBUILD.\nParameters Global parameters Name Description Value global.AppVersion [default: \u0026ldquo;\u0026rdquo;] Provide custom appVersion, to override the default one. All the ENBUILD images will be of the same version. To use indidual tag for each service set the tag on per service basis. \u0026quot;\u0026quot; global.domain What domain to use to expose the ENBUILD using istio or Ingress ijuned.com global.disable_tls_gitlab Set to true if you are using self-signed certificates false global.ingress.enabled Should we create the Ingress Resources ? false global.ingress.tls Is Ingress TLS enabled ? false global.ingress.tls_secret If Ingress is TLS enabled, Provide the Secret for the TLS Certificate. \u0026quot;\u0026quot; global.ingress.classname Ingress classname if enabled. \u0026quot;\u0026quot; global.ingress.annotations Ingress annotations if enabled. [] global.istio.enabled Should we create the Istio Resources ? false global.istio.gateway Istio gateway to use for creating Virtual Service. istio-system/main global.image.registry Container registry to pull images from registry.gitlab.com global.image.pullPolicy Container imagePullPolicy Always global.image.registry_credentials if the image.registry is private container registry, provide the credentials {} global.image.registry_credentials.username Container registry Username \u0026quot;\u0026quot; global.image.registry_credentials.password Container registry password \u0026quot;\u0026quot; Jupyterhub Parameters ENBUILD RabbitMQ parameters Name Description Value rabbitmq.enabled Set to false to use existing RabbitMQ true rabbitmq.replicaCount RabbitMQ replicaCount 1 rabbitmq.auth.username RabbitMQ username admin rabbitmq.auth.password RabbitMQ password SuperSecret rabbitmq.auth.erlangCookie RabbitMQ erlangCookie lamba rabbitmq.host If rabbitmq.enabled is false , provide the right rabbitmq endpoint \u0026quot;\u0026quot; rabbitmq.queue_prefix Queue Prefix for all RabbitMQ Queues enbuild ENBUILD Backend/DB parameters Name Description Value mongodb.enabled Set to true to Deploy the MongoDB. false mongodb.mongo_root_username DB username. If mongodb.enabled this is used to to set the username. Else this is username for existing Cosmos or DocumentDB \u0026quot;\u0026quot; mongodb.mongo_root_password DB Password. If mongodb.enabled this is used to to set the password. Else this is password for existing Cosmos or DocumentDB \u0026quot;\u0026quot; mongodb.mongo_server If mongodb.enabled is false , provide the right cosmosDB/DocumentDB endpoint \u0026quot;\u0026quot; mongodb.image.repository Container repository for mongodb Container enbuild-staging/vivsoft-platform-ui/mongodb mongodb.image.tag Container tag for mongodb Container 4.4.5 ENBUILD UI Services parameters Name Description Value enbuildUi.image.repository Container repository for enbuildUi enbuild-staging/vivsoft-platform-ui/enbuild-frontend enbuildUi.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildUi.replicas Container enbuildUI Replicas 1 enbuildUi.service_type enbuildUI service_type ClusterIP enbuildUi.node_port enbuildUI node_port 30080 enbuildUi.hostname enbuild service hostname. enbuildUi.hostname.global.domain becomes your FQDN enbuild enbuildUi.kiali_url kiali_url https://kiali.ijuned.com/kiali/ enbuildUi.grafana_url grafana_url https://grafana.ijuned.com/ enbuildUi.loki_url loki_url https://grafana.ijuned.com/d/liz0yRCZz/logs-app?orgId=1 enbuildUi.kubecost_url kubecost_url https://kubecost.ijuned.com/overview.html ENBUILD Backend Services parameters Name Description Value enbuildBk.image.repository Container repository for enbuildBk enbuild-staging/vivsoft-platform-ui/enbuild-backend enbuildBk.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildBk.replicas Container enbuildBk Replicas 1 enbuildBk.service_type enbuildBk service_type ClusterIP enbuildBk.encryption_key encryption_key to be used by Backend encryption_key ENBUILD USER Services parameters Name Description Value enbuildUser.image.repository Container repository for enbuildUser enbuild-staging/vivsoft-platform-ui/enbuild-user enbuildUser.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildUser.replicas Container enbuildUser Replicas 1 enbuildUser.service_type enbuildUser service_type ClusterIP ENBUILD Sync Services parameters Name Description Value enbuildSync.image.repository Container repository for enbuildSync enbuild-staging/vivsoft-platform-ui/enbuild-cronjob enbuildSync.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildSync.replicas Container enbuildSync Replicas 1 ENBUILD ML Services parameters Name Description Value enbuildMl.enabled Should we create the ENBUILD ML microservice ? false enbuildMl.image.repository Container repository for enbuildMl enbuild-staging/vivsoft-platform-ui/enbuild-ml enbuildMl.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildMl.replicas Container enbuildMl Replicas 1 enbuildMl.service_type enbuildMl service_type ClusterIP enbuildMl.jupyterhub.enabled Should we create the Jupyterhub for ENBUILD ML ? false ENBUILD GenAI Services parameters Name Description Value enbuildGenAI.enabled Should we create the ENBUILD GenAI microservice ? false enbuildGenAI.image.repository Container repository for enbuildGenAI enbuild-staging/vivsoft-platform-ui/enbuild-genai enbuildGenAI.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildGenAI.replicas Container enbuildGenAI Replicas 1 enbuildGenAI.service_type enbuildGenAI service_type ClusterIP enbuildGenAI.api_key api_key for OpenAI service. dummy ENBUILD Request Services parameters Name Description Value enbuildRequest.enabled Should we create the ENBUILD Request microservice ? false enbuildRequest.image.repository Container repository for enbuildRequest enbuild-staging/vivsoft-platform-ui/enbuild-request enbuildRequest.image.tag Container image tag. Skip to use the HelmChart appVersion as Image Tag undefined enbuildRequest.replicas Container enbuildRequest Replicas 1 enbuildRequest.service_type enbuildRequest service_type ClusterIP ","date":"0001-01-01","id":11,"permalink":"/docs/getting-started/helm-values/","summary":"ENBUILD Helm Chart Values The following key value pairs are used to configure ENBUILD.\nParameters Global parameters Name Description Value global.","tags":[],"title":"Helm Values"},{"content":"GitLab Resources The following table contains groups and repositories for ENBUILD.\nName Description iac-templates All ENBUILD Catalog Item Templates are located in this Group. vivsoft-platform The vivsoft-platform repository contains the source code for ENBUILD microservices. It is the codebase for building and maintaining the various microservices that collectively form the ENBUILD platform. baseos-rhel8 The basewos-rhel8 repository includes Packer configuration for creating a Red Hat 8 hardened Amazon Machine Image (AMI). It provides the necessary settings and scripts to build a secure and minimal RHEL8 AMI for ENBUILD use. enbuild-packer-rhel8 The enbuild-packer-rhel8 repository contains Packer configuration specifically tailored for creating a minimal ENBUILD AMI. It includes the necessary configuration details for building a lightweight and optimized AMI. hardened-gitlab-runner The hardened-gitlab-runner repository provides Dockerfile configuration for building a GitLab Runner container image with enhanced security measures. It is designed to create a secure environment for CI/CD processes within the ENBUILD ecosystem. enbuild-helm-chart The enbuild-helm-chart repository contains the Helm Chart for deploying ENBUILD. It provides the necessary configurations and definitions for using Helm to deploy and manage ENBUILD components in a Kubernetes environment. GitHub Resources The following table contains groups and repositories for ENBUILD.\nHere\u0026rsquo;s your markdown table for the provided data:\nName Description VivSoftOrg VivSoftOrg is an organizational group that houses all ENBUILD Catalog Item Templates. It serves as a centralized repository for various templates related to ENBUILD. The table includes the Name as a hyperlink directing to the corresponding link and provides a description alongside it.\n","date":"0001-01-01","id":12,"permalink":"/docs/getting-started/enbuild-repositories/","summary":"GitLab Resources The following table contains groups and repositories for ENBUILD.\nName Description iac-templates All ENBUILD Catalog Item Templates are located in this Group.","tags":[],"title":"ENBUILD Repositories"},{"content":"Follow these step-by-step instructions to deploy ENBUILD locally for testing.\nPrerequisites Existing Kubernetes Cluster Ensure that you have access to a Kubernetes cluster and obtain the KubeConfig file.\nYou can use rancher-desktop or k3d to spin up a local Kubernetes cluster.\nENBUILD Container Images Access to the ENBUILD container images are required for this deployment. These images are published to the VivSoft managed container reigistry on registry.gitLab.com. Make sure that you have the necessary credentials to pull these images.\nHelm CLI The Helm streamlines and automates Kubernetes deployments by managing charts, enabling users to easily package, version, and deploy complex applications.\nDeployment Steps: Following are the steps you will need to take to deploy ENBUILD to your Kubernetes cluster.\nAdd ENBUILD Helm Chart Repository To add the ENBUILD Helm chart repository, run the following command:\nhelm repo add vivsoft https://vivsoftorg.github.io/enbuild \u0026#34;vivsoft\u0026#34; has been added to your repositories ❗ Note: If the helm repo is already present on you machine , update it to get the latest version\n❯ helm repo update vivsoft Configure ENBUILD Helm Values Before deploying ENBUILD to the Kubernetes cluster, you will need to create a custom values.yaml file so that we can specify configurations unique to this deployment.\nFor local deployment however we require minimum deployment values.\n❗ Note: For more information about the complete set of ENBUILD Helm values click here!\nRefer to the example helm input file for guidance.\n⚡ Note: The imageCredentials section is only required if the images are not public.\nDeploy ENBUILD HELM Chart Make sure you update the values input to reference the values you created in Step 2. Execute the command below.\nhelm upgrade --install --namespace enbuild enbuild vivsoft/enbuild --create-namespace -f target/quick_install.yaml Release \u0026#34;enbuild\u0026#34; does not exist. Installing it now. NAME: enbuild LAST DEPLOYED: Fri Mar 22 17:37:23 2024 NAMESPACE: enbuild STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: 1. Get the application URL by running these commands: echo \u0026#34;Visit http://127.0.0.1:3000 to use your application after starting the port forward\u0026#34; kubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Validate ENBUILD Deployment Use the following commands to validate the ENBUILD pods are up and running.\nkubectl get pods -n enbuild NAME READY STATUS RESTARTS AGE enbuild-enbuild-genai-8488c86d6f-csfmn 1/1 Running 0 76m enbuild-enbuild-ui-56f5667d5b-4xckt 1/1 Running 0 76m enbuild-mongodb-0 1/1 Running 0 76m enbuild-rabbitmq-0 1/1 Running 0 76m enbuild-enbuild-backend-66676f8cd8-hxtbr 1/1 Running 0 76m enbuild-enbuild-user-b87d95b45-c79p6 1/1 Running 0 76m enbuild-enbuild-request-7c47c6d67b-j2fnd 1/1 Running 1 (73m ago) 76m enbuild-enbuild-ml-6f944ff759-ztdj6 1/1 Running 1 (73m ago) 76m enbuild-rabbitmq-1 1/1 Running 0 73m enbuild-rabbitmq-2 1/1 Running 0 72m enbuild-enbuild-mq-575c965764-zcnlg 1/1 Running 18 (6m24s ago) 76m ❗ Note: You might see restarts of the enbuild-enbuild-mq-* pod until the RabbitMQ service is up and running.\nValidate the ENBUILD services are setup correctly\nkubectl get services -n enbuild NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE enbuild-rabbitmq-headless ClusterIP None \u0026lt;none\u0026gt; 4369/TCP,5672/TCP,25672/TCP,15672/TCP 80s enbuild-mongo ClusterIP 10.43.230.6 \u0026lt;none\u0026gt; 27017/TCP 80s enbuild-enbuild-user ClusterIP 10.43.140.228 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-ui ClusterIP 10.43.110.47 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-backend ClusterIP 10.43.146.20 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-rabbitmq ClusterIP 10.43.54.197 \u0026lt;none\u0026gt; 5672/TCP,4369/TCP,25672/TCP,15672/TCP 80s Access ENBUILD Use the port forwarding command to access the ENBUILD UI using your web browser.\nkubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Forwarding from 127.0.0.1:3000 -\u0026gt; 8080 Forwarding from [::1]:3000 -\u0026gt; 8080 Navigate your web browser to http://127.0.0.1:3000. and set the admin password.\nAfter you set the initial admin password, you should see the ENBUILD home page with BigBang Catalog.\n⚡ Proceed to Configureing ENBUILD\nUninstall ENBUILD Use the following command to uninstall ENBUILD from your Kubernetes cluster.\nhelm uninstall enbuild -n enbuild release \u0026#34;enbuild\u0026#34; uninstalled ","date":"0001-01-01","id":13,"permalink":"/docs/how-to-guides/deploying-enbuild-for-local-testing/","summary":"Steps to deploy ENBUILD on local machine for quick testing","tags":[],"title":"Deploying ENBUILD for Local Testing"},{"content":"Follow these step-by-step instructions to configure ENBUILD.\nAfter you have successfully deployed the ENBUILD Helm Chart, you will need to configure the ENBUILD to deploy the Catalogs.\nSet the Admin Password You need to set the Admin Password before accessing the ENBUILD.\nConfigure the VCS Before deploying the catalog items, you need to configure the Version Control System (VCS). ENBUILD supports GitHub, GitLab VCS as of now.\nThese are the Version Control System where ENBUILD creates repositories when you deploy catalog item\nGITHUB By default , github is not enabled, so first you need to enable github, by clicking in it (only if you are planning to use Github as your VCS), and then set the following settings\nGithub Account \u0026ndash; The Github account where the deployment repositories will be created. Github Token \u0026ndash; The Token to be used to create deployment repositories Github Host \u0026ndash; The Github Host URL (e.g. https://github.com/) Github Branch \u0026ndash; The default branch for the deployment repositories (e.g. main) Github Host GQL URL \u0026ndash; The GraphQL API endpoint for the Github Host (e.g. https://api.github.com/graphql) Github Host URL \u0026ndash; The REST API endpoint for the Github Host (e.g. https://api.github.com) GITLAB Gitlab Host - The Gitlab Host (e.g. https://gitlab.com/) Gitlab Token - Gitlab Token to be used to create deployment repositories Gitlab Group - The Gitlab Group where the deployment repositories will be created Gitlab Namespace ID - The Gitlab Namespace ID of the group or user (e.g. 70306609) ❗ Note: You need to restart the enbuild-enbuild-mq-* pod after changing the VCS (GITHUB and GITLAB) setting.\nCatalog level Permissions There are four built-in roles available in ENBUILD:\nadmin appdev dataops devops You can check the roles by going to Admin \u0026ndash;\u0026gt; Roles\nAnd you can provide the permissions to each catalog as per your requirement for each catalog and roles.\nConfigure SSO By default ENBUILD uses Local authentication, but you can choose to use either of\nKEYCLOAK OKTA Configure KEYCLOAK If you plan to use KEYCLOAK as SSO for authentication, you will need to configure the following:\nKeycloak Backend URL \u0026ndash; The Keycloak URL to authenticate users. Keycloak Client ID \u0026ndash; The Keycloak Client ID to authenticate users. Keycloak Realm \u0026mdash; The Keycloak REALM to authenticate users. ❗ Note: To provide these details, you need to existing keyclaok or you need to install and configure keycloak.\nConfigure OKTA If you plan to use OKTA as SSO for authentication, you will need to configure the following:\nOkta Client URL \u0026ndash; The Okta URL to authenticate users. Okta Client Secret \u0026ndash; The Okta Client Secret to authenticate users. Okta Client ID \u0026mdash; The Okta Client ID to authenticate users. Okta Base URL \u0026mdash; The Okta Base URL to authenticate users. Okta Client Token \u0026mdash; The Okta Client Token to authenticate users. ❗ Note: To provide these details, you need to configure okta and obtain the details.\n","date":"0001-01-01","id":14,"permalink":"/docs/how-to-guides/configuring-enbuild/","summary":"Configuring ENBUILD after installation","tags":[],"title":"Configuring ENBUILD"},{"content":"Follow these step-by-step instructions to deploy ENBUILD locally using Iron Bank images for testing.\nPrerequisites Existing Kubernetes Cluster Ensure that you have access to a Kubernetes cluster and obtain the KubeConfig file.\nYou can use rancher-desktop or k3d to spin up a local Kubernetes cluster.\nHelm CLI The Helm streamlines and automates Kubernetes deployments by managing charts, enabling users to easily package, version, and deploy complex applications.\nAccess to ironbank Vivsoft has released the ENBUILD Container images in Ironbank in order to pull these images, you need to register in Ironbank and create credentials.\nDeployment Steps: Following are the steps you will need to take to deploy ENBUILD to your Kubernetes cluster.\nAdd ENBUILD Helm Chart Repository To add the ENBUILD Helm chart repository, run the following command:\nhelm repo add vivsoft https://vivsoftorg.github.io/enbuild \u0026#34;vivsoft\u0026#34; has been added to your repositories ❗ Note: If the helm repo is already present on you machine , update it to get the latest version\n❯ helm repo update vivsoft Configure ENBUILD Helm Values Before deploying ENBUILD to the Kubernetes cluster, you will need to create a custom values.yaml file so that we can specify configurations unique to this deployment.\nFor local deployment however we require minimum deployment values.\n❗ Note: For more information about the complete set of ENBUILD Helm values click here!\nRefer to the example helm input file to be used to pull images from IronBank for guidance.\nMake sure to replace the REGISTRY1_USER_NAME and REGISTRY1_PASSWORD , with your registry1 credentials. AppVersion with the ENBUILD application version you want to install. ( Make sure the images with the selected tags are present in IronBank)\nDeploy ENBUILD HELM Chart Make sure you update the values input to reference the values you created in Step 2. Execute the command below.\nhelm upgrade --install --namespace enbuild enbuild vivsoft/enbuild --create-namespace -f /tmp/quick_install_ib.yaml Release \u0026#34;enbuild\u0026#34; does not exist. Installing it now. NAME: enbuild LAST DEPLOYED: Fri Mar 22 17:37:23 2024 NAMESPACE: enbuild STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: 1. Get the application URL by running these commands: echo \u0026#34;Visit http://127.0.0.1:3000 to use your application after starting the port forward\u0026#34; kubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Validate ENBUILD Deployment Use the following commands to validate the ENBUILD pods are up and running.\nkubectl get pods -n enbuild NAME READY STATUS RESTARTS AGE enbuild-enbuild-genai-8488c86d6f-csfmn 1/1 Running 0 76m enbuild-enbuild-ui-56f5667d5b-4xckt 1/1 Running 0 76m enbuild-mongodb-0 1/1 Running 0 76m enbuild-rabbitmq-0 1/1 Running 0 76m enbuild-enbuild-backend-66676f8cd8-hxtbr 1/1 Running 0 76m enbuild-enbuild-user-b87d95b45-c79p6 1/1 Running 0 76m enbuild-enbuild-request-7c47c6d67b-j2fnd 1/1 Running 1 (73m ago) 76m enbuild-enbuild-ml-6f944ff759-ztdj6 1/1 Running 1 (73m ago) 76m enbuild-rabbitmq-1 1/1 Running 0 73m enbuild-rabbitmq-2 1/1 Running 0 72m enbuild-enbuild-mq-575c965764-zcnlg 1/1 Running 18 (6m24s ago) 76m ❗ Note: You might see restarts of the enbuild-enbuild-mq-* pod until the RabbitMQ service is up and running.\nValidate the ENBUILD services are setup correctly\nkubectl get services -n enbuild NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE enbuild-rabbitmq-headless ClusterIP None \u0026lt;none\u0026gt; 4369/TCP,5672/TCP,25672/TCP,15672/TCP 80s enbuild-mongo ClusterIP 10.43.230.6 \u0026lt;none\u0026gt; 27017/TCP 80s enbuild-enbuild-user ClusterIP 10.43.140.228 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-ui ClusterIP 10.43.110.47 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-enbuild-backend ClusterIP 10.43.146.20 \u0026lt;none\u0026gt; 80/TCP 80s enbuild-rabbitmq ClusterIP 10.43.54.197 \u0026lt;none\u0026gt; 5672/TCP,4369/TCP,25672/TCP,15672/TCP 80s Access ENBUILD Use the port forwarding command to access the ENBUILD UI using your web browser.\nkubectl --namespace enbuild port-forward svc/enbuild-enbuild-ui 3000:80 Forwarding from 127.0.0.1:3000 -\u0026gt; 8080 Forwarding from [::1]:3000 -\u0026gt; 8080 Navigate your web browser to http://127.0.0.1:3000. and set the admin password.\nAfter you set the initial admin password, you should see the ENBUILD home page with BigBang Catalog.\n⚡ Proceed to Configureing ENBUILD\nUninstall ENBUILD Use the following command to uninstall ENBUILD from your Kubernetes cluster.\nhelm uninstall enbuild -n enbuild release \u0026#34;enbuild\u0026#34; uninstalled ","date":"0001-01-01","id":15,"permalink":"/docs/how-to-guides/deploying-enbuild-using-ironbank-images/","summary":"Steps to deploy ENBUILD Using IronBank Images on local machine for quick testing","tags":[],"title":"Deploying ENBUILD Using IronBank Images"},{"content":"Bigbang Big Bang is a declarative, continuous delivery tool for deploying DoD hardened and approved packages into a Kubernetes cluster. More details are found Here\nPrerequisites Before you begin, ensure that you have the following prerequisites in place:\nIt does not matter how you create the kubernetes cluster , but you should have access to kubeconfig file. The cluster also have enough resources ( memory/cpu/) to run the bigbang nodes. The cluster-api server should be publicly accessible so that public gitlab ci-cd can access it. Once you deploy EKS or RKE2 from ENBUILD , it creates the SOPS KMS key. Once created and note down the ARN of the KMS key generated and create the sops.yaml file in below format , changing the ADD_YOUR_KMS_KEY_ARN_HERE with your actual SOPS KMS key.\nThis file we will use whole deploying BigBang.\n--- creation_rules: - kms: ADD_YOUR_KMS_KEY_ARN_HERE encrypted_regex: \u0026#34;^(data|stringData)$\u0026#34; Variables of creation_rules kms (string)\nDescription: The Amazon Resource Name (ARN) of the KMS key to be used for encryption. Default value: \u0026quot;ADD_YOUR_KMS_KEY_ARN_HERE\u0026quot; encrypted_regex (string)\nDescription: The regular expression pattern used to identify fields that should be encrypted. Default value: \u0026quot;^(data|stringData)$\u0026quot; Deploy BigBang Login to Enbuild -Enbuild Click on the Home Select the Platform One BigBang At the SOPS tab provide the sops.yaml created on SOPS prerequisite section. At the REPO tab , provide the\nRegistry URL — The container registry from where you are pulling the images for flux deployment. Registry Username - The container registry username to pull flux images Registry Password - The container registry password to pull flux images Repository Username - The gitlab repository username to pull the BigBang Helm chart. We have cloned the chart at chart Repository Password - The gitlab repository password to pull the BigBang Helm chart. (We have cloned the chart at chart) Next, choose the component Repo from the settings category and click on the SECRETS tab and provide the registryCredentialsand git credentials this is basically used by BigBang Helm chart to pull the container images and cloning the dependant helm charts used by bigbang.\nThe values of these will be same as previous section. registryCredentials: registry: registry.gitlab.com username: registry_username password: registry_password email: \u0026#34;\u0026#34; git: credentials: username: repository_usernane password: registry_password Similarly you can check other components and edit the values of the component deployment. If you feel the value is sensitive you can add that in secrets tab, so that enbuild will encrypt it using the KMS key provided before committing to the git repo. The different types of components avalable are listed below: settings Tool Repo -Domain used for BigBang created exposed services, can be overridden by individual packages. Service Mesh Tools Istio - Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments. Istio Operator - Instead of manually installing, upgrading, and uninstalling Istio, you can instead let the Istio operator manage the installation for you. This relieves you of the burden of managing different istioctl versions. Simply update the operator custom resource (CR) and the operator controller will apply the corresponding configuration changes for you. Jaeger - Distributed tracing observability platforms, such as Jaeger, are essential for modern software applications that are architected as microservices. Jaeger maps the flow of requests and data as they traverse a distributed system. These requests may make calls to multiple services, which may introduce their own delays or errors. Jaeger connects the dots between these disparate components, helping to identify performance bottlenecks, troubleshoot errors, and improve overall application reliability. Jaeger is 100% open source, cloud native, and infinitely scalable. Kiali - Kiali is a console for Istio service mesh. Kiali can be quickly installed as an Istio add-on, or trusted as a part of your production environment. Security Tools NeuVector - NeuVector is the only 100% open source, Zero Trust container security platform. Continuously scan throughout the container lifecycle. Remove security roadblocks. Bake in security policies at the start to maximize developer agility.\nFortify - Fortify is a comprehensive application security (AppSec) platform developed by Micro Focus. It empowers organizations to proactively identify and address vulnerabilities throughout the entire software development lifecycle (SDLC). Think of it as a security shield woven into the fabric of your development process, helping you build secure software from the ground up.\nTwistLock - Twistlock, now known as Palo Alto Networks Prisma Cloud, is a comprehensive cloud-native security platform designed to protect containerized applications and serverless workloads across cloud environments\nAnchore - Anchore is a container security and compliance platform that helps organizations discover, analyze, and enforce security and compliance policies for containerized applications and images. It ensures that container images are free from vulnerabilities and meet security and compliance standards before they are deployed.\nVault - Vaults work by encrypting each secret to help prevent unauthorized users from gaining access. They function mostly as an active storage container for secrets as well as an account management system for dealing with multiple privileged accounts across the company.\nSSO Tools Auth Service - An authentication service is an identity verification mechanism—similar to passwords—for apps, websites, or software systems. Keycloak - Keycloak is the standalone tool for identity and access management, which allows us to create a user database with custom roles and groups. We can use this information further to authenticate users within our application and secure parts of it based on predefined roles. Policy Management Tools Kyverno - Kyverno is a policy engine designed for Kubernetes platform engineering teams. It enables security, automation, compliance, and governance using policy-as-code. Kyverno Reporter - Monitoring and Observability Tool for the PolicyReport CRD with an optional UI. Kyverno Policies - Kyverno policies can validate, mutate, generate, and cleanup Kubernetes resources, and verify image signatures and artifacts to help secure the software supply chain. Cluster Auditor - Cluster Auditor is a tool that pulls constraints from the Kubernetes API, transforms them, and inserts them into Prometheus to be displayed in a Grafana Dashboard. Gatekeeper - Gatekeeper HQ is a vendor and contract lifecycle management platform designed for companies of all sizes. It offers a secure contract and vendor repository that stores every file, interaction, and piece of metadata relating to all your contract agreements. The platform provides features for vendor management, contract management, Kanban workflow, collaboration, and reporting, with the ability to extend functionality through additional modules and integration with over 220 third-party solutions. Logging Tools ECK operator - The ECK operator, or Elastic Cloud on Kubernetes, is built on the Kubernetes Operator pattern. It extends Kubernetes’ orchestration capabilities to support the setup and management of various Elastic Stack components on Kubernetes, including Elasticsearch, Kibana, APM Server, Enterprise Search, Beats, Elastic Agent, Elastic Maps Server, and Logstash Fluentbit - Fluent Bit is a super fast, lightweight, and highly scalable logging and metrics processor and forwarder. It is the preferred choice for cloud and containerized environments. EFK stack -The EFK stack is a popular open-source logging solution for Kubernetes environments. It stands for: Elasticsearch: A search and analytics engine. Fluentd: An open-source data collector for unified logging layer. Kibana: A visualization dashboard for Elasticsearch. Loki - Grafana Loki is a set of open source components that can be composed into a fully featured logging stack. A small index and highly compressed chunks simplifies the operation and significantly lowers the cost of Loki. Promtail - Promtail is an agent which ships the contents of local logs to a private Grafana Loki instance or Grafana Cloud. It is usually deployed to every machine that runs applications which need to be monitored. Monitoring Tools Monitoring - Together, these tools provide a powerful platform for aggregating, analyzing, and visualizing logs in Kubernetes clusters, helping with monitoring, troubleshooting, and gaining insights from applications. Thanos - Thanos is based on Prometheus. With Thanos, Prometheus always remains as an integral foundation for collecting metrics and alerting using local data. Tempo - Tempo is an open source, easy-to-use, and high-scale distributed tracing backend. Sonarqube - SonarQube is a self-managed, automatic code review tool that systematically helps you deliver Clean Code. As a core element of our Sonar solution. Tempo - Tempo is an open source, easy-to-use, and high-scale distributed tracing backend. Grafana - Grafana is the open source analytics \u0026amp; monitoring solution for every database. Metrics Server - The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it isn\u0026rsquo;t deployed by default in Amazon EKS clusters. Development Tools Sonarqube - SonarQube is a self-managed, automatic code review tool that systematically helps you deliver Clean Code. As a core element of our Sonar solution.\nNexus - Nexus is a robust tool designed for managing and organizing artifacts throughout the software development lifecycle.\nHarbor - Harbor is an open source registry that secures artifacts with policies and role-based access control, ensures images are scanned and free from vulnerabilities, and signs images as trusted. Harbor, a CNCF Graduated project, delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud native compute platforms like Kubernetes and Docker.\nGitLab- GitLab is a web-based DevOps lifecycle tool that integrates various stages of the software development process into a single platform.\nCI/CD Tools ArgoCD - Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. GitLab Runner - GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline. Proxy Tool Haproxy - HAProxy is a free, open source high availability solution, providing load balancing and proxying for TCP and HTTP-based applications by spreading requests across multiple servers. Backup Tool: Velero - Velero is an open source tool to safely backup and restore, perform disaster recovery, and migrate Kubernetes cluster resources and persistent volumes. Object Storage Tools: Minio - MinIO is a high-performance, S3 compatible object store. It is built for large scale AI/ML, data lake and database workloads. It is software-defined and runs on any cloud or on-premises infrastructure. MinIO is dual-licensed under open source GNU AGPL v3 and a commercial enterprise license. Minio Operator - The MinIO Operator installs a Custom Resource Definition (CRD) to support describing MinIO tenants as a Kubernetes object. See the MinIO Operator CRD Reference for complete documentation on the MinIO CRD. Communication Tools Mattermost - Mattermost is a secure collaboration platform for accelerating mission critical work in complex environments. Metrics Server - The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it isn\u0026rsquo;t deployed by default in Amazon EKS clusters. One important component setting while deploying BigBang is\ndomain: dev.bigbang.mil which is present in Settings → Repo → Values. This defines the istio ingress domain on which the bigbang applications will be available.\nYou also have to provide the right tls certificate and key for the same domain defined above in the Component → Service Mesh → Istio → Secrets tab. So that you can access the bigbang applications in browser without any security/certificate warning.\nAfter providing all the input values, provide the name for your deployment proceed to Infrastructure section, and provide your kubeconfig file - Paste your kubeconfig file Select AWS as your cloud and provide your AWS credentials. These AWS credentials are used to encrypt the secrets using SOPS. So make sure the IAM user of these credentials is having kms:Encrypt and kms:Decrypt permissions. Once all inputs are provided click on Deploy Stack\n","date":"0001-01-01","id":16,"permalink":"/docs/how-to-guides/deploying-bigbang/","summary":"Steps to Deploy Bigbang","tags":[],"title":"Deploying Bigbang"},{"content":"Kubernetes Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management.Originally designed by Google, the project is now maintained by a worldwide community of contributors, and the trademark is held by the Cloud Native Computing Foundation.\nDeploy Kubernetes Login to Enbuild -Enbuild Click on the Home Select the Kubernetes Choose the component RKE2 from the DISTRO category and click on the VALUES tab and provide the Credentials RKE2 RKE2, also known as RKE Government, is Rancher\u0026rsquo;s next-generation Kubernetes distribution.\nIt is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.\nDeploy RKE2 VPC Configuration create_vpc (true or false)\nDescription: The create_vpc variable decides if a new Virtual Private Cloud (VPC) should be created. Default value: false vpc_cidr (string)\nDescription: The vpc_cidr variable defines the IP address range for the VPC. Default value: \u0026quot;10.0.0.0/16\u0026quot; NAT Gateway Configuration enable_nat_gateway (true or false)\nDescriprion: The enable_nat_gateway variable decides if a NAT Gateway should be enabled. Default value: true single_nat_gateway (true or false)\nDescription: The single_nat_gateway decides if only one NAT Gateway should be used. Default value: true vpc_id (string)\nDescription: The vpc_id is used to Specify an existing VPC to use. Needed if create_vpc is false. Default value:: \u0026quot;vpc-39b8da44\u0026quot; subnets (list of strings)\nDescription: Lists the IDs of subnets within the VPC. Needed if create_vpc is false. Example: [\u0026quot;subnet-5817463e\u0026quot;, \u0026quot;subnet-f191cdd0\u0026quot;] EC2 Instance Configuration instance_type (string)\nDescription: The instance_type specifies the type of EC2 instance to use. Default value: \u0026quot;t3.large\u0026quot; associate_public_ip_address (true or false)\nDescription: The associate_public_ip_address decides if the instance should have a public IP address. Default value: true controlplane_internal (true or false)\nWhat it does: Decides if the control plane should be internal only. Default value: false servers (number)\nDescription: Number of EC2 instances to create. Default value: 1 Auto Scaling Group (ASG) Configuration asg (object) Description: The variable asgis used to the Auto Scaling Group (ASG). Properties: min (number): Minimum number of instances in the ASG. Default value: 1 max (number): Maximum number of instances in the ASG. Default value: 10 desired (number): Desired number of instances in the ASG. Default value: 1 suspended_processes (list of strings): List of processes to suspend. Default value: [] termination_policies (list of strings): List of termination policies. Default value: [\u0026quot;Default\u0026quot;] Block Device Mapping block_device_mappings (object) What it does: Configuration for the block device (storage). Properties: size (number): Size of the volume in GB. Default value: 50 type (string): Type of the volume. Default value: \u0026quot;gp2\u0026quot; Registry Mirror Configuration create_registry1_mirror (true or false)\nDescription: create_registry1_mirror decides if a mirror for the https://registry1.dso.mil container registry should be created. Default value: false registry1_mirror_proxy_address (string)\nDescription: This address should have a proper container registry up and running and listening Example: \u0026quot;http://44.210.192.97:5000\u0026quot; After providing all the input values, provide the name for your deployment proceed to Infrastructure section,\nSelect AWS as your cloud and provide your AWS credentials.\nOnce all inputs are provided click on Deploy Stack\nChoose the component EKS from the DISTRO category and follow the previous steps. EKS Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service to run Kubernetes in the AWS cloud and on-premises data centers. In the cloud, Amazon EKS automatically manages the availability and scalability of the Kubernetes control plane nodes responsible for scheduling containers, managing application availability, storing cluster data, and other key tasks. With Amazon EKS, you can take advantage of all the performance, scale, reliability, and availability of AWS infrastructure, as well as integrations with AWS networking and security services. On-premises, EKS provides a consistent, fully-supported Kubernetes solution with integrated tooling and simple deployment to AWS Outposts, virtual machines, or bare metal servers.\nDeploy EKS VPC Configuration create_vpc (true or false)\nDescription: The create_vpc variable decides if a new Virtual Private Cloud (VPC) should be created. Default value: true vpc_cidr (string)\nDescription: The vpc_cidr variable defines the IP address range for the VPC. Default value: \u0026quot;10.0.0.0/16\u0026quot; If you don\u0026rsquo;t want to create a new VPC, set create_vpc to false and provide the following variables:\nvpc_id (string)\nDescription: The vpc_id specifies an existing VPC to use. Needed if create_vpc is false. Example: \u0026quot;vpc-39b8da44\u0026quot; subnet_ids (list of strings)\nDescription: Lists the IDs of subnets within the VPC. Needed if create_vpc is false. Example: [\u0026quot;subnet-1242491c\u0026quot;, \u0026quot;subnet-5817463e\u0026quot;] EKS Cluster Configuration cluster_name (string)\nDescription: The cluster_name variable specifies the name of the EKS cluster. Default value: \u0026quot;juned-eks\u0026quot; cluster_version (string)\nDescription: The cluster_version variable specifies the version of the EKS cluster. Default value: \u0026quot;1.29\u0026quot; cluster_endpoint_public_access (true or false)\nDescription: The cluster_endpoint_public_access variable decides if the EKS cluster endpoint should be publicly accessible. Default value: true cluster_endpoint_private_access (true or false)\nDescription: The cluster_endpoint_private_access variable decides if the EKS cluster endpoint should be privately accessible. Default value: false EKS Node Groups Configuration eks_node_groups_min_size (number)\nDescription: The eks_node_groups_min_size variable specifies the minimum number of nodes in the EKS node group. Default value: 1 eks_node_groups_max_size (number)\nDescription: The eks_node_groups_max_size variable specifies the maximum number of nodes in the EKS node group. Default value: 5 eks_node_groups_desired_size (number)\nDescription: The eks_node_groups_desired_size variable specifies the desired number of nodes in the EKS node group. Default value: 1 NAT Gateway Configuration enable_nat_gateway (true or false)\nDescription: The enable_nat_gateway variable decides if a NAT Gateway should be enabled. Default value: true single_nat_gateway (true or false)\nDescription: The single_nat_gateway variable decides if only one NAT Gateway should be used. Default value: true Kubernetes Configuration create_kubeconfig (true or false) Description: The create_kubeconfig variable decides if a kubeconfig file should be created for the EKS cluster. Default value: true EC2 Instance Configuration instance_types (list of strings) Description: The instance_types variable specifies the types of EC2 instances to use for the EKS nodes. Default value: [\u0026quot;t3.large\u0026quot;] Registry Mirror Configuration create_registry1_mirror (true or false)\nDescription: The create_registry1_mirror variable decides if a mirror for the https://registry1.dso.mil container registry should be created. Default value: false registry1_mirror_proxy_address (string)\nDescription: The registry1_mirror_proxy_address variable specifies the proxy address for the registry1 mirror. Example: \u0026quot;http://44.210.192.97:5000\u0026quot; ","date":"0001-01-01","id":17,"permalink":"/docs/how-to-guides/deploying-kubernetes/","summary":"Steps to Deploy Kubernets","tags":[],"title":"Deploying Kubernetes"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nAccess to Platform1 registry Kubernetes cluster is up and running and you have access to it via kubectl command. Helm 3 installed on your system. Login to Platform1 registry Login to Platform1 registry by using the following command:\nhelm registry login registry1.dso.mil/bigbang WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config Username: Juned_Memon Password: Login Succeeded Create Namespace and Image pull secret We need to create the istio-system and istio-operator namespaces.\nkubectl create ns istio-operator kubectl create ns istio-system Next, we need to create the imagePullSecret for pulling the images from Platform1 registry.\nFirst export the REGISTRY1_USER and REGISTRY1_PASSWORD with your P1 credentials.\nexport REGISTRY1_USER=\u0026lt;YOUR_REGISTRY1_USER\u0026gt; export REGISTRY1_PASSWORD=\u0026lt;YOUR_REGISTRY1_PASSWORD\u0026gt; Next, create the imagePullSecret for pulling the images from Platform1 registry.\nkubectl create secret -n istio-operator docker-registry private-registry --docker-server=registry1.dso.mil --docker-username=$REGISTRY1_USER --docker-password=$REGISTRY1_PASSWORD kubectl create secret -n istio-system docker-registry private-registry --docker-server=registry1.dso.mil --docker-username=$REGISTRY1_USER --docker-password=$REGISTRY1_PASSWORD Install istio-operator Helm charts Now install istio-operator Helm charts using the P1 Helm chart:\nhelm upgrade --install --namespace istio-operator istio-operator oci://registry1.dso.mil/bigbang/istio-operator --version 1.20.4-bb.0 --set imagePullSecrets[0]=\u0026#34;private-registry\u0026#34; --set createNamespace=false Verify the istio-operator pod is up and running:\n# kubectl get po -n istio-operator NAME READY STATUS RESTARTS AGE istio-operator-7b5fff8cfb-h6w4k 1/1 Running 0 18s Optional - Install CertManager Before installing the stio-controlplane we need a wildcard-cert secret containing the SSL certificate for the domain on which are planning to expose the virtual services.\nYou can use CertManager manage that TLS certificates and keys, or you can create them manually using openssl.\nHere, we will install CertManager and use self-signed-certificat.\nTo deploy a proper certificate using CertManager refer the official Documentation\nkubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml # kubectl get pods --namespace cert-manager NAME READY STATUS RESTARTS AGE cert-manager-67c98b89c8-g428w 1/1 Running 0 5m12s cert-manager-cainjector-5c5695d979-7qczq 1/1 Running 0 5m12s cert-manager-webhook-7f9f8648b9-2bt85 1/1 Running 0 5m12s Create a self signed cluster issuer\n--- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned-ca-issuer spec: selfSigned: {} --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: selfsigned-ca namespace: cert-manager spec: isCA: true commonName: selfsigned-ca secretName: root-secret privateKey: algorithm: ECDSA size: 256 issuerRef: name: selfsigned-ca-issuer kind: ClusterIssuer group: cert-manager.io --- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned spec: ca: secretName: root-secret --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: self-sign-cert namespace: istio-system spec: secretName: wildcard-cert commonName: ijuned.com dnsNames: - ijuned.com - \u0026#34;*.ijuned.com\u0026#34; issuerRef: name: selfsigned kind: ClusterIssuer --- Apply the configurations\nkubectl apply -f self-sign-cert.yaml Install istio-controlplane Before installing the stio-controlplane we need a wildcard-cert secret containing the SSL certificate for the domain on which are planning to expose the virtual services.\nYou can create them manaully if you have the tls.key and tls.cert of your private certificate.\nOtherwise you can use Certmanager\nTo install the istio controlplane Helm chart.\nThe domain input that you provide, will be used to create a host entry in the istio Gateway named main\nhelm upgrade --install --namespace istio-system istio oci://registry1.dso.mil/bigbang/istio --version 1.20.4-bb.0 --set imagePullSecrets[0]=\u0026#34;private-registry\u0026#34; --set domain=\u0026#34;ijuned.com\u0026#34; ","date":"0001-01-01","id":18,"permalink":"/docs/how-to-guides/installing-istio/","summary":"Steps to Install Istio","tags":[],"title":"Installing Istio"},{"content":"Creating an AWS EC2 Instance Using the ENBUILD AMI or Marketplace Item This guide will walk you through the steps to create an Amazon EC2 instance using the AMI named ENBUILD.\nThe ENBUILD AMI has ENBUILD pre-installed in it, along with the gitlab.\nThe Gitlab also has Catalog repositories of BigBang and EKS pre-populated with it.\nPrerequisites An AWS account with the necessary permissions to create EC2 instances. Basic familiarity with the AWS Management Console. Steps 1. Log in to the AWS Management Console Go to AWS Management Console. Enter your AWS account credentials to log in. 2. Navigate to the EC2 Dashboard In the AWS Management Console, type \u0026ldquo;EC2\u0026rdquo; in the search bar and select EC2 from the dropdown list. This will take you to the EC2 Dashboard. 3. Launch an Instance On the EC2 Dashboard, click on the Launch Instance button. 4. Choose an Amazon Machine Image (AMI) In the Choose an Amazon Machine Image (AMI) step, go to the My AMIs tab or AWS Marketplace AMI\u0026rsquo;s Use the search bar to find the AMI named ENBUILD. Select the ENBUILD AMI by clicking the Select button next to it. 5. Choose an Instance Type Select an appropriate instance type based on your requirements (e.g., t2.micro for free tier eligible users). Click the Next: Configure Instance Details button. 6. Configure Instance Details Configure the instance details as needed. The default settings are typically sufficient for most users. Click the Next: Add Storage button. 7. Add Storage Adjust the storage settings if necessary. The default settings usually suffice. Click the Next: Add Tags button. 8. Add Tags (Optional) Add tags to your instance to help organize and manage your resources. Click the Next: Configure Security Group button. 9. Configure Security Group Create a new security group or select an existing one. If creating a new security group, add rules to allow necessary inbound traffic (e.g., SSH for Linux instances, RDP for Windows instances). Click the Review and Launch button. 10. Review and Launch Review your instance configuration to ensure everything is correct. Click the Launch button. 11. Select a Key Pair In the Select an existing key pair or create a new key pair dialog: Select an existing key pair, or Create a new key pair and download the private key file (.pem). Make sure to keep this file safe, as you will need it to connect to your instance. Check the acknowledgment box and click the Launch Instances button. 12. View Your Instance Click the View Instances button to go to the EC2 Dashboard and view your newly created instance. Wait for the instance to enter the running state. 13. Connect to Your Instance Select your instance in the EC2 Dashboard. Click the Connect button and follow the instructions to connect to your instance using SSH (for Linux instances) or RDP (for Windows instances). Congratulations! You have successfully launched an EC2 instance using the ENBUILD AMI.\nAccessing Services of ENBUILD The services can be accessed after launching the instance using the AMI at the following URLs with the given public IP (NODE_PUBLIC_IP) of the node:\nEnbuild: http://NODE_PUBLIC_IP:30080/ Gitlab: http://NODE_PUBLIC_IP:32080/ Hauler: http://NODE_PUBLIC_IP:30500/v2/_catalog Default credentials for Gitlab are root/supersecretpassword, and the token for the root user is glpat-RuJrDn4yUuPRJySjJdZh.\nAdditional Resources AWS EC2 Documentation AWS AMI Documentation If you encounter any issues or have questions, refer to the AWS documentation or seek support from AWS.\n","date":"0001-01-01","id":19,"permalink":"/docs/how-to-guides/using-enbuild-ami/","summary":"Steps to use ENBUILD AMI to launch ENBUILD instance","tags":[],"title":"Using ENBUILD AMI"},{"content":"Introduction: In production Kubernetes environments, exposing the ENBUILD UI service requires careful consideration to ensure accessibility and security. While the Quick install of ENBUILD facilitates local testing through port forwarding, deploying in a production scenario demands a more robust approach. This document outlines various options available for exposing the ENBUILD UI service outside the Kubernetes cluster.\nOption 1: Expose UI using Kubernetes Service Type LoadBalancer Setting the service type to LoadBalancer enables external access to the ENBUILD UI service. Simply configure the service type as LB to allow external traffic. Refer to the example helm input file for guidance.\nOption 2: Use Service Type NodePort Configuring the service type as NodePort provides accessibility by exposing a specific port on all nodes in the cluster. Access the ENBUILD UI using the designated node port.\nRefer to the example helm input file for guidance.\nOption 3: Use Ingress Controller Installation and configuration of an Ingress controller within the Kubernetes cluster are prerequisites for this option. Expose the ENBUILD UI service through Ingress configuration for enhanced routing and management of external traffic. Refer to the example helm input file for guidance.\nOption 4: Expose Using Istio Virtual Service (Istio installation)[(docs/how-to-guides/installing-istio/)] and configuration are required for leveraging this option. Set the istio.enabled parameter to true and provide the necessary configurations, such as the Istio Virtual Service, to expose the ENBUILD UI service. Refer to the example helm input file for guidance.\n","date":"0001-01-01","id":20,"permalink":"/docs/how-to-guides/exposing-enbuild-ui/","summary":"Steps to Install Istio","tags":[],"title":"Exposing ENBUILD UI"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nAccess to Platform1 registry Kubernetes cluster is up and running and you have access to it via kubectl command. Helm 3 installed on your system. Login to Platform1 registry Login to Platform1 registry by using the following command:\nhelm registry login registry1.dso.mil/bigbang WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /root/.kube/config WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /root/.kube/config Username: Juned_Memon Password: Login Succeeded Create Namespace and Image pull secret We need to create the keycloak namespace\nkubectl create ns keycloak Next, we need to create the imagePullSecret for pulling the images from Platform1 registry.\nFirst export the REGISTRY1_USER and REGISTRY1_PASSWORD with your P1 credentials.\nexport REGISTRY1_USER=\u0026lt;YOUR_REGISTRY1_USER\u0026gt; export REGISTRY1_PASSWORD=\u0026lt;YOUR_REGISTRY1_PASSWORD\u0026gt; Next, create the imagePullSecret for pulling the images from Platform1 registry.\nkubectl create secret -n keycloak docker-registry private-registry --docker-server=registry1.dso.mil --docker-username=$REGISTRY1_USER --docker-password=$REGISTRY1_PASSWORD Install keycloak Helm charts Now install keycloak Helm charts using the P1 Helm chart:\nCreate a keycloak-input-values.yaml\n## Overrides the default args for the Keycloak container args: - \u0026#34;start\u0026#34; - \u0026#34;--http-port=8080\u0026#34; - \u0026#34;--import-realm\u0026#34; # Additional environment variables for Keycloak # https://www.keycloak.org/server/all-config extraEnv: |- - name: KC_HTTP_ENABLED value: \u0026#34;true\u0026#34; - name: KC_PROXY value: edge - name: KC_HOSTNAME_STRICT value: \u0026#34;false\u0026#34; - name: KC_HOSTNAME_STRICT_HTTPS value: \u0026#34;false\u0026#34; - name: KC_HTTP_RELATIVE_PATH value: /auth helm upgrade --install --namespace keycloak keycloak oci://registry1.dso.mil/bigbang/keycloak --version 23.0.7-bb.2 -f keycloak-input-values.yaml Verify the keycloak pod is up and running:\n# kubectl get po -n keycloak NAME READY STATUS RESTARTS AGE keycloak-0 1/1 Running 0 105s keycloak-postgresql-0 1/1 Running 0 16m Access keycloak UI Access the Keycloak web interface using Port forwarding\n❯ kubectl port-forward svc/keycloak-http 9090:80 -n keycloak Forwarding from 127.0.0.1:9090 -\u0026gt; 8080 Forwarding from [::1]:9090 -\u0026gt; 8080 Handling connection for 9090 Handling connection for 9090 Handling connection for 9090 Get the Keycloak admin credentials Use the following command to get the admin credentials for the keycloak instance:\nUSER=$(kubectl get secret keycloak-env -n keycloak -o jsonpath=\u0026#39;{.data.KEYCLOAK_ADMIN_PASSWORD}\u0026#39; | base64 --decode) PASSWORD=$(kubectl get secret keycloak-env -n keycloak -o jsonpath=\u0026#39;{.data.KEYCLOAK_ADMIN}\u0026#39; | base64 --decode) echo \u0026#34;Keycloak Admin user is $USER and password is $PASSWORD\u0026#34; Configure the Keycloak Create a realm keyclaok realm is a logical container for a set of related users, applications, and groups.\nAccess the http://localhost:9090/auth/admin/#/realms and click on Add realm.\nTo save we have provided a realm.json file. All you have to do is import it.\nClick on the Browse button and provide the realm.json file. Create a enbuild-ui Client Clients are entities that can request Keycloak to authenticate a user. Most often, clients are applications and services that want to use Keycloak to secure themselves and provide a single sign-on solution.\nClients can also be entities that just want to request identity information or an access token so that they can securely invoke other services on the network that are secured by Keycloak.\nClick on the Clients menu from the left pane. All the available clients for the selected Realm will get listed here.\nRather creating Clients manually we will use Import so that the you do not have provide the details manually.\nTo create a new client, click on Import client.\nClick on the Browse button and provide the enbuild-ui.jsonfile.\nand Save the client.\nAfter import make sure you configure the valid redirect URI\u0026rsquo;s.\nYou have to provide the URI(FQDN) of ENBUILD that you have configured while installing the ENBUILD Helm chart.\nCreate a enbuild Client Use the same method to Import the enbuild.json client.\nAfter you save the enbuild client. Go to the Credentials tab of the enbuild client to get the Client Secret which is required for configuring the (Keycloak in ENBUILD admin setting)[../configuring-enbuild/#configure-keycloak]\nRealm Roles and Groups ❗ Note: All these roles and groups are already created in the realm, when we imported the realms.\nENBUILD support different roles , and based on these roles, differnt type of catalog can be visible.\nBy default\nENBUILD_ADMIN ENBUILD-APPDEV ENBUILD-DATAOPS ENBUILD-DEVOPS ENBUILD_USER these Groups are present in the realm we imported.\nThese Groups mapped to the following roles in one to one relationship.\nadmin \u0026ndash; ENBUILD_ADMIN appdev \u0026ndash; ENBUILD-APPDEV dataops \u0026ndash; ENBUILD-DATAOPS devops \u0026ndash; ENBUILD-DEVOPS user \u0026ndash; ENBUILD_USER Create Users Users are entities that are able to log into your system. They can have attributes associated with themselves like email, username, address, phone number, and birth day. They can be assigned group membership by clicking on the Join Groups button or Groups tab from the profile.\nClick on the Add Member button and select the group you want to add the user to, then click on the Add button.\nExposing the KeyCloak service in Kubernetes. So far we have accessed the keycloak service from the browser by using the port-forwarding and then accessing it via local-port. But for production usage and to configure it as SSO inside ENBUILD we need to expose it on a public IP address.\nThere are multiple ways to achive that -\nExpose the keycloak-http service as LoadBalancer - This way the kubernertes will create a external loadbalancer and expose the service on a public IP address. Create an Ingress resource for the keycloak-http service - This way we can use a ingress controller to route traffic to the keycloak service based on the hostname. If you have istio deployed and configured in your cluster, then expose it as virtual service. This is the sample virtaul service configurations you can use ❗ Note: Make sure to adjust the hosts to the right value to which you want to expose the service.\nCreate a DNS record for the keycloak after you have exposed the keycloak-http service using any of the above methods, you can create a DNS record pointing to the public IP address or FQDN of the loadbalncer.\ne.g. if you have exposed the service using the istio virtual service you will need to create a DNS record for this service in your DNS provider.\nThe IP address of the DNS will be the EXTERNAL-IP of the istio-ingressgateway service, you can find that using the command below.\nkubectl get svc -n istio-system istio-ingressgateway -o jsonpath=\u0026#39;{.status.loadBalancer.ingress[*].ip}\u0026#39; Create a DNS type A record using the IP address from the command above.\nOnce done you can proceed to configure keycloak as SSO for ENBUILD\n","date":"0001-01-01","id":21,"permalink":"/docs/how-to-guides/install-and-configure-keycloak-for-enbuild-sso/","summary":"Install and Configure Keycloak for ENBUILD SSO","tags":[],"title":"Install and Configure Keycloak for ENBUILD SSO"},{"content":"Overview This guide outlines the steps required to create a new catalog template repository in your GitHub or Gitlab account.\nPrerequisites You must have a GitHub and or Gitlab account and have access to the orgnizations you are part of. Familiarity with Git and Github Actions is recommended but not required. Steps Create a new repository\nNavigate to your GitHub dashboard and click on the \u0026lsquo;+\u0026rsquo; button in the top left corner, then select New repository. Enter a name for your catalog template repository initialize it with a README file, and make it public if you want your catalog templates to be publicly available.\nAdd the images and infrastructure files\nAdd the following files to your repository:\nimages/\u0026lt;catalog-name\u0026gt;.png \u0026ndash; This is the image ENBUILD will disaply while showing the catalog in the UI. images/\u0026lt;component-name\u0026gt;.png \u0026ndash; You have to create images for all the compoments for your catalog. This is the image ENBUILD will disaply while showing the component of catalog in the UI. infra/ , all your Terraform infrastructure files should go here scripts/, all your scripts should go here values.yaml \u0026ndash; This file will contain all the default values for your templates. Add the CI-CD Pipeline files\nIf its a GitHub repo:\nCreate a file .github/workflows/main.yml and add the deployment steps to it. Disable the github actions for this repo. Since this is a template repository, you don\u0026rsquo;t want your templates being deployed when someone adds a commit to this repo. If its a Gitlab repo:\nCreate a file gitlab-ci.yml and add the deployment steps to it ⚡ Note: The Gitlab CI expects the CI file name to be .gitlab-ci.yml, but since the repository we are operating on is a template repository and we do not want to run our pipeline locally for this Repository, hence the name of the file is changed to gitlab-ci.yml and ENBUILD will rename this to .gitlab-ci.yml in the target deployment repository of this catalog.\nReference Catalog Repository See the example Github catalog template repository and\nexample Gitlab catalog template repository\nfor an example of what the template repository should look like.\nNext Steps Creating a new catalog entry in ENBUILD ","date":"0001-01-01","id":22,"permalink":"/docs/how-to-guides/creting-new-catalog-template-repository/","summary":"Creting new catalog template repository","tags":[],"title":"Creting new catalog template repository"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nENBUILD is installed and you have admin access to it. You have created the Catalog templates repository for the catalog item (either in Gitlab/Github) If the catalog template repository is private, you have aquired the token with readonly access to the repository. Adding a new repository Navigate to the Repositories tab of the Admin panel and click on Connect New Respository. You will be presented with the following form:\nChoose your VCS: Choose the VCS of your catalog, either Gitlab or Github. In this example, we will use Gitlab.\nSet up Repository Credentials: Enter the repository URL in the Repository URL field.\nIf the repository is private, enter the Username in the Username field and the Token in the Password field.\nClick on Connect check the connection of the repository.\nThere are two ways of adding a new catalog item to ENBUILD:\nAdding a New Catalog Item Manually Adding a New Catalog Item using exported JSON Adding a New Catalog Item Manually. Login to ENBUILD as admin user. Navigate to Manage Catalogs tab and click on Create Catalog. You will be presented with the following form:\nChoose your VCS: Choose the VCS of your catalog, either Gitlab or Github. In this example, we will use Gitlab.\nSet up Catalog Details: Enter a Name for your catalog. This name is displayed to the user while they are browsing the ENBUILD. Choose a Type for your catalog items. The type defines the type of the catalog. Choose the template Repository for your catalog items from the dropdown menu. This is the template repository that you have created in previous step (or) click on the Add new button to add a new repository. If the template repository is private, Check the IsPrivate button and provide the Readonly Access Token in the Token field. Provide the Project ID of the template repository. Enter a Readme File Path this is the path of the README file that you want to disaply when user clicks on your catalog item. Enter a Values Folder Path this is the directory of the Values files for the components. Choose the Branch for your catalog template to be used. (only required in Gitlab) Enter an Image Path of the image to be displayed for a catalog item in ENBUILD UI. Select Multi Select. This feature allows users to select multiple components from same catagary in a catalog. If enabled the user can install/enable multiple components at once. Otherwise a single component is installed/enabled at a time for a component catagory. Click on Save And Continue to proceed to add Components for the Catalogs Set up Component Details Enter a Name for your component. Select a Tool Type for your component item. This is used to group components in a single group. Choose the component Repository for your component items from the repository dropdown (or) click on the Add new button to add a new repository. Ommit if the component and catalog are in same repository. Provide the Project ID of the template repository. Ommit if the component and catalog are in same repository. Choose the Branch as Ref for your component template to be used. (only required in Gitlab) Ommit if the component and catalog are in same repository. Enter a Variable File Path this is the input variable file which ENBUILD will display for the components , and user will use to change the beheviour of the deployment. Enter an Image Path of the image to be displayed for a component item in ENBUILD UI. Select Mandatory. If the Catalog is created enabling the Multi Select . Enabling this Mandatory will set This component to be enabled by default in ENBUILD UI. Click on Save And Continue to proceed to add Infrastrcture for the Catalogs Set up Infrastrcture Details for the catalogs Here you can select all the infrastructure providers that the catalog needs to be installed. For now we support AWS ,Azure Oracle and KUBERNETES You can select 1 or multiple providers for your catalog, but you must have at least one provider selected for the catalog to be valid. And your catalog template should have provision to support all the selected providers.\nAdding the Permission for the catalogs to ENBUILD ROLES Once the Catalog is created , you need to add permissions to the catalog for a particuler role that can have access to this catalog.\nAnd you can provide the permissions to each catalog as per your requirement for each catalog and roles.\nAdding a New Catalog Item using exported JSON The other way of creating the Catalog Item is providing the raw catalog json file that you have exported from ENBUILD or uploading the json file containing the catalog information.\nLogin to ENBUILD as admin user. Navigate to Manage Catalogs tab and click on Create Catalog. and then Choose the VCS of your catalog, either Gitlab or Github. In this example, we will use Gitlab. Click on Upload Json button to to proceed to import the catalog using JSON Here you can provide the raw json of any catalog exported from ENBUILD UI. OR upload a file from your local machine having the catalog json. ","date":"0001-01-01","id":23,"permalink":"/docs/how-to-guides/adding-new-catalog-item-in-enbuild/","summary":"Adding new Catalog Item in ENBUILD","tags":[],"title":"Adding new Catalog Item in ENBUILD"},{"content":"Prerequisites Before you begin, ensure that you have the following prerequisites in place:\nKubernetes cluster is up and running and you have access to it via kubectl command. Helm 3 installed on your system. Create Namespace and Image pull secret To install the Nginx Ingress Controller to your cluster, you’ll first need to add its repository to Helm by running:\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx The output will be:\n\u0026#34;ingress-nginx\u0026#34; has been added to your repositories Update your system to let Helm know what it contains:\nhelm repo update ingress-nginx install the Nginx ingress: run the following command to install the Nginx ingress:\nhelm install nginx-ingress ingress-nginx/ingress-nginx --set controller.publishService.enabled=true This command installs the Nginx Ingress Controller from the stable charts repository, names the Helm release nginx-ingress, and sets the publishService parameter to true.\nOnce it has run, you will receive an output similar to this:\nNAME: nginx-ingress LAST DEPLOYED: Wed Apr 10 16:19:24 2024 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The ingress-nginx controller has been installed. It may take a few minutes for the load balancer IP to be available. You can watch the status by running \u0026#39;kubectl get service --namespace default nginx-ingress-ingress-nginx-controller --output wide --watch\u0026#39; An example Ingress that makes use of the controller: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example namespace: foo spec: ingressClassName: nginx rules: - host: www.example.com http: paths: - pathType: Prefix backend: service: name: exampleService port: number: 80 path: / # This section is only required if TLS is to be enabled for the Ingress tls: - hosts: - www.example.com secretName: example-tls If TLS is enabled for the Ingress, a Secret containing the certificate and key must also be provided: apiVersion: v1 kind: Secret metadata: name: example-tls namespace: foo data: tls.crt: \u0026lt;base64 encoded cert\u0026gt; tls.key: \u0026lt;base64 encoded key\u0026gt; type: kubernetes.io/tls ... Helm has logged what resources it created in Kubernetes as a part of the chart installation.\nOptional - Install CertManager To use TLS with ingress we need to create a certificate with propr TLS data. You can create that manually. But for reference we will use the Cert-manager to manage our certificates.\nHere, we will install CertManager and use self-signed-certificate.\nTo deploy a proper certificate using CertManager refer the official Documentation\nkubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml # kubectl get pods --namespace cert-manager NAME READY STATUS RESTARTS AGE cert-manager-67c98b89c8-g428w 1/1 Running 0 5m12s cert-manager-cainjector-5c5695d979-7qczq 1/1 Running 0 5m12s cert-manager-webhook-7f9f8648b9-2bt85 1/1 Running 0 5m12s Create a self signed cluster issuer\n--- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned-ca-issuer spec: selfSigned: {} --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: selfsigned-ca namespace: cert-manager spec: isCA: true commonName: selfsigned-ca secretName: root-secret privateKey: algorithm: ECDSA size: 256 issuerRef: name: selfsigned-ca-issuer kind: ClusterIssuer group: cert-manager.io --- apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned spec: ca: secretName: root-secret --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: self-sign-cert namespace: kube-system spec: secretName: wildcard-cert commonName: ijuned.com dnsNames: - ijuned.com - \u0026#34;*.ijuned.com\u0026#34; issuerRef: name: selfsigned kind: ClusterIssuer --- Apply the configurations\nkubectl apply -f self-sign-cert.yaml Follow the the official Documentation for using cert-manager issuers other than self-sign.\nInstall ENBUILD with exposing service using Ingress To install ENBUILD with exposing frontend serivice using Ingress you can use these example helm input file.\n❗ Note: Make sure to change the domain and the certificate name as per your requirments.\nCreate DNS records Run this command to watch the ingress-ingress-nginx-controller Load Balancer become available:\nkubectl --namespace default get services -o wide -w nginx-ingress-ingress-nginx-controller This command fetches the Nginx Ingress service in the default namespace and outputs its information, but the command does not exit immediately. With the -w argument, it watches and refreshes the output when changes occur.\nWhile waiting for the Load Balancer to become available, you may receive a pending response:\nAfter some time has passed, the IP address of your newly created Load Balancer will appear:\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR nginx-ingress-ingress-nginx-controller LoadBalancer 10.43.254.211 192.168.0.108 80:31730/TCP,443:32755/TCP 5m56s app.kubernetes.io/component=controller,app.kubernetes.io/instance=nginx-ingress,app.kubernetes.io/name=ingress-nginx Next, you’ll need to ensure that your domains like enbuild.ijuned.com and rabbitmq.ijuned.com are pointed to the Load Balancer via A records. This is done through your DNS provider. To configure your DNS records follow your DNS provider documentaion.\nYou’ve installed the Nginx Ingress maintained by the Kubernetes community. It will route HTTP and HTTPS traffic from the Load Balancer to appropriate back-end Services configured in the Ingress Resources.\nOnce the DNS / Host entry is added you can access the ENBUILD using the created ingress domain\n❯ kubectl get ing -n enbuild NAME CLASS HOSTS ADDRESS PORTS AGE enbuild-enbuild-ing nginx enbuild.ijuned.com 192.168.0.108 80, 443 10m ","date":"0001-01-01","id":24,"permalink":"/docs/how-to-guides/installing-nginx-ingress/","summary":"Steps to Install Nginx Ingress","tags":[],"title":"Installing Nginx Ingress"},{"content":"You can export a catalog item from ENBUILD in JSON format. You can use this JSON to commit in the version control system for a backup. And then use this json to import to another ENBUILD instance.\nLogin to ENBUILD as admin user. Navigate to Manage Catalogs tab and you will see the list of all active catalogs in the ENBUILD instance. Select the Catalog that you want to export and then at the Actions coloumn select the export icon. ","date":"0001-01-01","id":25,"permalink":"/docs/how-to-guides/exporting-catalog-item-from-enbuild/","summary":"Exporting Catalog Item from ENBUILD","tags":[],"title":"Exporting Catalog Item from ENBUILD"},{"content":"This cheat sheet provides commonly used kubectl commands for managing Kubernetes clusters.\nBasic Commands List all pods kubectl get pods List all pods in a specific namespace kubectl get pods -n \u0026lt;namespace\u0026gt; List all nodes kubectl get nodes List all services kubectl get services How to check logs of the pods kubectl logs \u0026lt;pod-name\u0026gt; How to check logs of the pods in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; How to check logs of the pods in a specific container in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container in a specific namespace with timestamps kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps How to check logs of the pods in a specific container in a specific namespace with timestamps and limit the output to 10 lines kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps --tail 10 ","date":"0001-01-01","id":26,"permalink":"/docs/troubleshooting/kubectl-cheat-sheet/","summary":"This cheat sheet provides commonly used kubectl commands for managing Kubernetes clusters.\nBasic Commands List all pods kubectl get pods List all pods in a specific namespace kubectl get pods -n \u0026lt;namespace\u0026gt; List all nodes kubectl get nodes List all services kubectl get services How to check logs of the pods kubectl logs \u0026lt;pod-name\u0026gt; How to check logs of the pods in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; How to check logs of the pods in a specific container in a specific namespace kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; How to check logs of the pods in a specific container in a specific namespace with timestamps kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps How to check logs of the pods in a specific container in a specific namespace with timestamps and limit the output to 10 lines kubectl logs \u0026lt;pod-name\u0026gt; -c \u0026lt;container-name\u0026gt; -n \u0026lt;namespace\u0026gt; --timestamps --tail 10 ","tags":[],"title":"Kubectl Cheat Sheet"},{"content":" About Q: Who is behind this project?\nA: VivSoft! 🐘 VivSoft is focused on solving complex problems in the public sector using innovative technologies. VivSoft is working with business leaders in federal, state and local government to help mission owners accelerate innovation using DevSecOps, Cloud, AI/ML and Blockchain Technologies.\nQ: What problem does ENBUILD solve?\nA: ENBUILD\u0026rsquo;s goal is to empower organizations to leverage Kubernetes and cloud-native technologies effectively while minimizing the complexity and overhead associated with deployment and management tasks. By offering pre-configured catalog items and promoting best practices, ENBUILD enables organizations to streamline their development workflows, reduce time to market, and achieve their product development goals more efficiently.\nCosts and Licensing Fees Q: Is ENBUILD free to use?\nA: Yes, ENBUILD is free to use.\nQ: What license does ENBUILD use?\nA: ENBUILD utilizes the Apache License, which is an open-source software license recognized for its flexibility and permissive nature. This license allows users to freely use, modify, and distribute the software, whether for personal, commercial, or open-source projects. For more detailed information about the Apache License and its implications, please refer to the official Apache Software Foundation website or consult the license file included with the ENBUILD software distribution.\nSecurity Q: What dependencies does ENBUILD have?\nA: ENBUILD, being a Kubernetes native application, relies on certain dependencies to function optimally. These dependencies include:\nKubernetes Cluster: ENBUILD requires a Kubernetes cluster to operate. This ensures that ENBUILD can leverage the scalability, resilience, and orchestration capabilities provided by Kubernetes, thereby enabling efficient deployment and management of containerized applications. Version Control System (VCS) for ENBUILD Catalog Item Deployments: ENBUILD utilizes a Version Control System for managing and deploying ENBUILD Catalog Items. Currently, ENBUILD supports integration with two popular VCS platforms:\nGitLab: ENBUILD seamlessly integrates with GitLab, allowing users to leverage the robust features of GitLab for managing and versioning their ENBUILD Catalog Items. This includes support for both the Software as a Service (SaaS) offering of GitLab and self-hosted deployments of GitLab instances.\nGitHub: ENBUILD also supports integration with GitHub, enabling users to utilize GitHub\u0026rsquo;s collaborative features and version control capabilities for ENBUILD Catalog Item deployments. Similar to GitLab, ENBUILD supports both the SaaS offering of GitHub and self-hosted deployments of GitHub Enterprise instances.\nBy supporting these Version Control Systems, ENBUILD provides users with flexibility and choice, allowing them to seamlessly integrate ENBUILD into their existing development workflows while leveraging the capabilities of their preferred VCS platform.\nFor further details on setting up ENBUILD dependencies and integration with specific Version Control Systems, please refer to the ENBUILD documentation or reach out to our support team for assistance.\nDeployment Q: What types of Kubernetes distributions is ENBUILD compatible with?\nA: ENBUILD has been deployed and tested on the following distributions of Kubernetes:\nAmazon EKS (Elastic Kubernetes Service): ENBUILD is fully compatible with Amazon EKS, allowing users to deploy and manage ENBUILD on Amazon Web Services\u0026rsquo; managed Kubernetes service. Azure AKS (Azure Kubernetes Service): ENBUILD seamlessly integrates with Azure AKS, enabling users to deploy and run ENBUILD on Microsoft Azure\u0026rsquo;s managed Kubernetes service. Rancher K3D: ENBUILD supports deployment on Rancher K3D, a lightweight Kubernetes distribution designed for local development and testing purposes. Rancher RKE2: ENBUILD is compatible with Rancher RKE2, an enterprise-grade Kubernetes distribution optimized for production workloads. Configuration Q: What is an ENBUILD Catalog Item (CI)?\nA: An ENBUILD Catalog Item, often abbreviated as CI, serves as a standardized template project designed to streamline the deployment and management of various infrastructure components and applications within the ENBUILD ecosystem. These Catalog Items are meticulously crafted by developers to encapsulate pre-configured settings, best practices, and reusable components, providing users with a simplified and consistent approach to deploying complex infrastructure and applications.\nENBUILD Catalog Items are tailored to support a diverse range of use cases and technologies, including:\nTerraform Infrastructure as Code (IaC): Catalog Items for Terraform enable users to define and manage cloud infrastructure resources using Infrastructure as Code principles. These Catalog Items offer pre-defined templates and configurations for provisioning resources on popular cloud platforms such as AWS, Azure, and Google Cloud Platform, facilitating rapid deployment and automation of infrastructure provisioning tasks.\nKubernetes Distributions (e.g., Amazon EKS, Azure AKS): Catalog Items for Kubernetes distributions provide users with pre-configured templates for deploying and managing Kubernetes clusters on various cloud providers, such as Amazon EKS (Elastic Kubernetes Service) and Azure AKS (Azure Kubernetes Service). These Catalog Items simplify the setup and configuration of Kubernetes clusters, enabling users to leverage the scalability and agility of Kubernetes for containerized application deployment and orchestration.\nHelm Deployments (e.g., Big Bang): Catalog Items for Helm deployments offer pre-packaged configurations and charts for deploying applications and services using Helm, a popular package manager for Kubernetes. These Catalog Items streamline the deployment of complex applications by providing ready-to-use Helm charts and configurations, reducing the time and effort required for setting up and configuring application environments.\nBy leveraging ENBUILD Catalog Items, developers gain access to a curated library of templates and configurations that serve as starting points for their projects. These Catalog Items not only accelerate the development and deployment process but also promote consistency, reliability, and best practices across projects within the ENBUILD ecosystem.\nQ: What is an Version Control System (VCS)?\nA: A Version Control System (VCS) is a fundamental tool used in software development to manage and track changes to source code, configuration files, and other project assets over time. It allows multiple developers to collaborate on a project concurrently while maintaining a history of all modifications made to the project files.\nIn the context of ENBUILD, a Version Control System (VCS) plays a crucial role in managing and deploying ENBUILD Catalog Items, which are template projects designed to facilitate the deployment of infrastructure components and applications within the ENBUILD ecosystem. ENBUILD supports integration with popular VCS platforms such as GitLab and GitHub, providing users with the flexibility to version control their Catalog Items and streamline the deployment process.\nKey features and benefits of using a Version Control System (VCS) include:\nHistory Tracking: VCS systems maintain a detailed history of changes made to project files, including who made the changes and when they were made. This allows developers to review past revisions, track the evolution of the project, and revert to previous versions if necessary.\nCollaboration: VCS systems enable seamless collaboration among team members by providing mechanisms for sharing and synchronizing changes to project files. Multiple developers can work on the same codebase simultaneously without risking conflicts or data loss.\nBranching and Merging: VCS systems support branching and merging workflows, allowing developers to create separate branches to work on specific features or fixes independently. Branches can later be merged back into the main codebase, ensuring a streamlined and organized development process.\nAuditing and Compliance: VCS systems offer auditing capabilities that help maintain compliance with regulatory requirements and internal policies. Organizations can track and monitor all changes made to project files, ensuring accountability and transparency in the development process.\nBy leveraging a Version Control System (VCS) such as GitLab or GitHub, ENBUILD users can effectively manage their Catalog Items, collaborate with team members, track changes, and maintain a consistent and reliable deployment workflow.\nChange Control Q: What is the Release schedule?\nA: To Be Determined. 📆\n","date":"0001-01-01","id":27,"permalink":"/docs/faq/frequently-asked-questions/","summary":"About Q: Who is behind this project?\nA: VivSoft! 🐘 VivSoft is focused on solving complex problems in the public sector using innovative technologies.","tags":[],"title":"Frequently Asked Questions"},{"content":"Glossary of terms\nTerm Definition DevSecOps This is a combination of development, security, and operations. Imagine a team working on creating a software, where everyone from programmers to security experts and IT professionals collaborate closely from the start to the end of a project. This approach ensures that the software is developed quickly, securely, and efficiently. Containerization Think of this as packing your entire software, with everything it needs to run (like code, libraries, and system tools), into a single package or \u0026lsquo;container\u0026rsquo;. This container can then be easily moved and run on different computers or servers, much like how you might pack your belongings into a suitcase when traveling, ensuring you have everything you need wherever you go. Kubernetes This is like a conductor for an orchestra, but instead of managing musical instruments, it manages containers (those packages mentioned earlier). Kubernetes helps in organizing and automating the deployment, scaling (adjusting the size or capacity), and management of containerized applications, ensuring they run smoothly and efficiently. Helm Deployments Helm is akin to a package manager for Kubernetes. Just as you might use a tool on your computer to install, update, or manage software, Helm does this for Kubernetes applications. It works with packages called \u0026lsquo;charts\u0026rsquo;, which are collections of information necessary to create a standardized deployment on Kubernetes. This makes installing and managing Kubernetes applications as easy as installing apps on your smartphone. Terraform Infrastructure Deployments Terraform is a tool that allows you to describe your infrastructure (like servers, databases, and networks) using code. This approach lets you set up and manage your infrastructure through code files, which can be versioned, reused, and shared. Imagine building a model city where you can design and rearrange buildings, roads, and parks with a few clicks. Terraform does something similar for computer infrastructure, allowing for easy adjustments and replication across different environments. GitLab and GitHub Integration GitLab and GitHub are platforms that allow developers to store their code, track changes, and collaborate with others. Integrating with these platforms means ENBUILD can automatically interact with your code stored on GitLab or GitHub, helping automate parts of the development process like testing and deployment, much like how social media apps can share information to keep everything in sync. CI/CD (Continuous Integration/Continuous Deployment) This is a practice in software development where every time a developer makes changes to the code (continuous integration), those changes are automatically tested and then deployed to the live application (continuous deployment). It\u0026rsquo;s like a factory assembly line for software, where new features are added, tested, and made available to users seamlessly and efficiently. NoSQL Database Unlike traditional databases that store data in tables, a NoSQL database uses a more flexible format (like key-value pairs, documents, or graphs). This flexibility allows for easier storage and retrieval of data in various formats, making it suitable for applications that handle diverse and large amounts of data, such as social networks or e-commerce sites. Helm Chart A Helm chart is a package containing all the necessary information to run an application or service on Kubernetes. It includes details on how the application should be configured and deployed, similar to a recipe that outlines the ingredients and steps needed to make a dish. RBAC (Role-Based Access Control) RBAC is a method for restricting system access to authorized users. It\u0026rsquo;s like having different keys for different rooms in a building; depending on your role (e.g., manager, employee), you\u0026rsquo;re given keys (access) only to the areas you need to perform your job. Iron Bank Accredited Containers Iron Bank refers to a repository of secure container images that have been approved for use within certain secure environments, such as government or military. Think of it as a library of vetted, safe-to-use building blocks for software that meet high security standards. GitOps This is a way to manage your infrastructure and applications by using Git (a version control system) as the single source of truth. It\u0026rsquo;s like maintaining a detailed blueprint for a machine; any changes to the blueprint automatically update the machine, ensuring it always matches the design specifications. KubeFlow KubeFlow is a project aimed at making deployments of machine learning (ML) workflows on Kubernetes simple, portable, and scalable. Imagine if you could set up a complex scientific experiment with all its equipment and processes in a box, move it anywhere, and have it work the same way every time—that\u0026rsquo;s what KubeFlow does for ML projects. Landing Zones In cloud computing, a landing zone is a predefined environment with a set of policies, tools, and computing resources. It\u0026rsquo;s prepared ground for new applications or services, ensuring they have a secure and efficient place to operate from the moment they\u0026rsquo;re deployed. Service Mesh A service mesh is a layer that controls how different parts of an application share data with one another. It\u0026rsquo;s like a sophisticated system within a busy city that manages how cars (data) navigate the streets (network) to ensure smooth traffic flow and delivery of passengers (services) to their destinations safely and efficiently. ","date":"0001-01-01","id":28,"permalink":"/docs/faq/glossary/","summary":"Glossary of terms\nTerm Definition DevSecOps This is a combination of development, security, and operations. Imagine a team working on creating a software, where everyone from programmers to security experts and IT professionals collaborate closely from the start to the end of a project.","tags":[],"title":"Glossary"},{"content":" ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, revolutionizes the application deployment process. At its essence, ArgoCD enables organizations to manage and automate the deployment of applications through Git repositories, promoting a declarative approach to configuration and versioning. It continuously monitors the desired state of applications defined in Git and automatically reconciles any divergences with the current state in the Kubernetes cluster. This ensures that applications are consistently deployed and maintained across different environments. ArgoCD\u0026rsquo;s intuitive user interface provides visibility into the deployment status, allowing for easy tracking and rollbacks. With support for multiple clusters and repositories, ArgoCD empowers teams to achieve efficient, scalable, and auditable continuous delivery workflows in Kubernetes environments.\nSample ArgoCD Commands Below is a list of common ArgoCD CLI commands for managing Kubernetes applications:\nLogging in to Argo CD Server To log in to the Argo CD server, use the following command:\nargocd login \u0026lt;argocd-server-url\u0026gt; --username \u0026lt;username\u0026gt; --password \u0026lt;password\u0026gt; Setting the Current Context Before executing any Argo CD CLI commands, you need to set the current context to the Argo CD server:\nargocd context \u0026lt;argocd-server-url\u0026gt; Listing Applications List all applications managed by Argo CD:\nargocd app list Getting Information about an Application Retrieve detailed information about a specific application:\nargocd app get \u0026lt;application-name\u0026gt; Syncing an Application Manually sync an application with its target state:\nargocd app sync \u0026lt;application-name\u0026gt; Setting Sync Options You can set various sync options for an application. For example:\nargocd app set \u0026lt;application-name\u0026gt; --sync-policy \u0026lt;policy\u0026gt; Deleting an Application Delete an application from Argo CD:\nargocd app delete \u0026lt;application-name\u0026gt; Configuring Auto-Sync Enable or disable auto-sync for an application:\nargocd app auto-sync \u0026lt;application-name\u0026gt; --\u0026lt;enable/disable\u0026gt; Viewing Application Resources List Kubernetes resources managed by an application:\nargocd app resources \u0026lt;application-name\u0026gt; Accessing Argo CD Web UI You can also access the Argo CD Web UI by running:\nargocd open Logging out of Argo CD Server To log out of the Argo CD server, run:\nargocd logout Further Reading Read argocd Official Documentation ","date":"0001-01-01","id":29,"permalink":"/docs/references/argocd/","summary":"ArgoCD, a declarative, GitOps continuous delivery tool for Kubernetes, revolutionizes the application deployment process. At its essence, ArgoCD enables organizations to manage and automate the deployment of applications through Git repositories, promoting a declarative approach to configuration and versioning.","tags":[],"title":"ArgoCD"},{"content":" Big Bang is a declarative, continuous delivery tool for deploying DoD hardened and approved packages into a Kubernetes cluster.\nUsage \u0026amp; Scope Big Bang\u0026rsquo;s scope is to provide publicly available installation manifests for packages required to adhere to the DoD DevSecOps Reference Architecture and additional useful utilities. Big Bang packages are broken into three categories:\nCore: Core packages are a group of capabilities required by the DoD DevSecOps Reference Architecture, that are supported directly by the Big Bang development team. The specific capabilities that are considered core currently are Service Mesh, Policy Enforcement, Logging, Monitoring, and Runtime Security.\nAddons: Addon packages are any packages/capabilities that the Big Bang development team directly supports that do not fall under the above core definition. These serve to extend the functionality/features of Big Bang.\nCommunity: Community packages are any packages that are maintained by the broader Big Bang community (users, vendors, etc). These packages could be alternatives to core or addon packages, or even entirely new packages to help extend usage/functionality of Big Bang.\nIn order for an installation of Big Bang to be a valid installation/configuration you must install/deploy a core package of each category (for additional details on categories and options see here).\nBig Bang also builds tooling around the testing and validation of Big Bang packages. These tools are provided as-is, without support.\nBig Bang is intended to be used for deploying and maintaining a DoD hardened and approved set of packages into a Kubernetes cluster. Deployment and configuration of ingress/egress, load balancing, policy auditing, logging, monitoring, etc. are handled via Big Bang. Additional packages (e.g. ArgoCD, GitLab) can also be enabled and customized to extend Big Bang\u0026rsquo;s baseline. Once deployed, the Kubernetes cluster can be used to add mission specific applications.\nFurther Reading Read big bang Official Documentation Checkout big bang on GitHub ","date":"0001-01-01","id":30,"permalink":"/docs/references/platform-one-big-bang/","summary":"Big Bang is a declarative, continuous delivery tool for deploying DoD hardened and approved packages into a Kubernetes cluster.","tags":[],"title":"Platform One Big Bang"},{"content":" GitLab stands as a comprehensive DevOps platform, providing end-to-end solutions for source code management, continuous integration, delivery, security, and more. As an integrated tool, GitLab facilitates collaboration among development, operations, and security teams, streamlining the entire software development lifecycle. With its version control capabilities based on Git, GitLab allows teams to efficiently manage and track changes in their codebase. Beyond version control, GitLab\u0026rsquo;s robust CI/CD pipelines automate the building, testing, and deployment of applications, ensuring rapid and reliable delivery. The platform also emphasizes security with built-in features for code scanning, vulnerability management, and compliance tracking. GitLab\u0026rsquo;s all-in-one approach fosters collaboration, transparency, and efficiency, making it a preferred choice for organizations aiming to achieve seamless and integrated DevOps workflows.\nFurther Reading Read gitlab Official Documentation ","date":"0001-01-01","id":31,"permalink":"/docs/references/gitlab/","summary":"GitLab stands as a comprehensive DevOps platform, providing end-to-end solutions for source code management, continuous integration, delivery, security, and more.","tags":[],"title":"GitLab"},{"content":" The Helm CLI serves as a powerful package manager for Kubernetes applications, streamlining and simplifying the deployment and management of complex containerized applications. At its core, Helm utilizes charts—pre-configured packages of Kubernetes resources—to encapsulate and version entire applications. With the Helm CLI, users can effortlessly install, upgrade, and roll back applications, ensuring consistent and reproducible deployments across different environments. Its templating system allows for easy customization of configurations, while the Helm repository facilitates the sharing and distribution of charts. Whether orchestrating microservices or deploying scalable applications, Helm proves to be an indispensable tool for developers and operators seeking efficiency and consistency in Kubernetes environments. Sample Helm Commands Below is a list of common Helm CLI commands for managing Kubernetes applications:\nInitializing Helm Initialize Helm in your Kubernetes cluster:\nhelm init Adding a Helm Repository Add a repository containing Helm Charts:\nhelm repo add stable https://charts.helm.sh/stable Searching for Helm Charts Searching for Helm charts in the added repositories:\nhelm search repo \u0026lt;keyword\u0026gt; Installing a Helm Chart Install a Helm chart into your Kubernetes cluster:\nhelm install \u0026lt;release-name\u0026gt; \u0026lt;chart-name\u0026gt; Listing Installed Helm Releases List all installed Helm releases:\nhelm list Getting Information about a Release Get information about a specific Helm release:\nhelm status \u0026lt;release-name\u0026gt; Upgrading a Helm Release Upgrade a Helm release to a new version:\nhelm upgrade \u0026lt;release-name\u0026gt; \u0026lt;chart-name\u0026gt; Deleting a Helm Release Delete a Helm release from your Kubernetes cluster:\nhelm delete \u0026lt;release-name\u0026gt; Viewing Helm Release History View the history of changes for a Helm release:\nhelm history \u0026lt;release-name\u0026gt; Uninstalling Helm To uninstall Helm from your Kubernetes cluster, run:\nhelm reset Further Reading Read helm Official Documentation ","date":"0001-01-01","id":32,"permalink":"/docs/references/helm/","summary":"The Helm CLI serves as a powerful package manager for Kubernetes applications, streamlining and simplifying the deployment and management of complex containerized applications.","tags":[],"title":"Helm"},{"content":" Istio, a robust and open-source service mesh platform, redefines how microservices communicate within a Kubernetes environment. Acting as a dedicated layer for managing and securing microservice interactions, Istio provides a comprehensive set of tools for traffic management, load balancing, and observability. By intelligently routing and controlling the flow of traffic between services, Istio enhances resilience, fault tolerance, and overall service reliability. Its built-in security features, such as mutual TLS authentication and access control, fortify communication channels between microservices. Additionally, Istio\u0026rsquo;s observability capabilities, including distributed tracing and metrics collection, offer insights into application performance. With Istio, organizations can effortlessly implement a resilient and secure microservices architecture, ultimately improving the manageability and reliability of their containerized applications. Sample Istio Commands Below is a list of common Istio CLI commands for managing Istio service mesh:\nInstalling Istio Install Istio into your Kubernetes cluster:\nistioctl install Verifying Istio Installation Verify that Istio components are installed correctly:\nistioctl verify-install Listing Istio Virtual Services List all Istio Virtual Services in the cluster:\nistioctl get virtualservices Creating a Virtual Service Create a new Istio Virtual Service:\nistioctl create -f virtual-service.yaml Updating a Virtual Service Update an existing Istio Virtual Service:\nistioctl replace -f virtual-service.yaml Deleting a Virtual Service Delete an Istio Virtual Service:\nistioctl delete virtualservice \u0026lt;virtual-service-name\u0026gt; Listing Istio Gateways List all Istio Gateways in the cluster:\nistioctl get gateways Viewing Istio Service Mesh Dashboard Access the Istio Service Mesh dashboard:\nistioctl dashboard kiali Generating Istio Service Graph Generate a service graph for Istio services:\nistioctl analyze Viewing Istio Proxy Logs View logs from Istio proxies:\nistioctl proxy-config log \u0026lt;pod-name\u0026gt; Upgrading Istio Upgrade Istio to a newer version:\nistioctl upgrade -f istio-upgrade.yaml Uninstalling Istio Uninstall Istio from your Kubernetes cluster:\nistioctl x uninstall --purge Further Reading Read istio Official Documentation ","date":"0001-01-01","id":33,"permalink":"/docs/references/istio/","summary":"Istio, a robust and open-source service mesh platform, redefines how microservices communicate within a Kubernetes environment. Acting as a dedicated layer for managing and securing microservice interactions, Istio provides a comprehensive set of tools for traffic management, load balancing, and observability.","tags":[],"title":"Istio"},{"content":" K3D, a lightweight and versatile tool, simplifies the management and deployment of Kubernetes clusters by bringing the power of Kubernetes into a single-node environment. Designed for simplicity and speed, K3D allows developers and operators to spin up Kubernetes clusters with ease, making it an ideal choice for local development, testing, and CI/CD pipelines. Leveraging containerd and other containerization technologies, K3D offers a minimalistic yet efficient Kubernetes experience. Users can create, scale, and delete clusters effortlessly, making it a valuable tool for scenarios where resource constraints or rapid cluster provisioning are crucial. With K3D, developers can focus on building and testing applications in a Kubernetes-like environment without the complexity of managing large-scale clusters, thereby accelerating the development lifecycle.\nSample K3D Commands Below is a list of basic K3D CLI commands for managing Kubernetes clusters:\nCreating a Kubernetes Cluster Create a new Kubernetes cluster using k3d:\nk3d cluster create \u0026lt;cluster-name\u0026gt; Listing Kubernetes Clusters List all existing Kubernetes clusters managed by k3d:\nk3d cluster list Getting Information about a Cluster Retrieve detailed information about a specific Kubernetes cluster:\nk3d cluster get \u0026lt;cluster-name\u0026gt; Accessing Kubernetes Cluster Set the kubeconfig context to the newly created Kubernetes cluster:\nexport KUBECONFIG=\u0026#34;$(k3d kubeconfig write \u0026lt;cluster-name\u0026gt;)\u0026#34; Deleting a Kubernetes Cluster Delete a Kubernetes cluster managed by k3d:\nk3d cluster delete \u0026lt;cluster-name\u0026gt; Starting a Kubernetes Cluster Start a previously stopped Kubernetes cluster:\nk3d cluster start \u0026lt;cluster-name\u0026gt; Stopping a Kubernetes Cluster Stop a running Kubernetes cluster:\nk3d cluster stop \u0026lt;cluster-name\u0026gt; Scaling Nodes Scale the number of worker nodes in the cluster:\nk3d node create \u0026lt;node-name\u0026gt; --replicas \u0026lt;num-replicas\u0026gt; Exporting kubeconfig Export the kubeconfig file for a cluster:\nk3d kubeconfig write \u0026lt;cluster-name\u0026gt; Further Reading Read k3d Official Documentation ","date":"0001-01-01","id":34,"permalink":"/docs/references/k3d/","summary":"K3D, a lightweight and versatile tool, simplifies the management and deployment of Kubernetes clusters by bringing the power of Kubernetes into a single-node environment.","tags":[],"title":"K3D"},{"content":"","date":"2023-09-07","id":35,"permalink":"/","summary":"","tags":[],"title":"ENBUILD"},{"content":"","date":"2023-09-07","id":36,"permalink":"/docs/","summary":"","tags":[],"title":"Docs"},{"content":"","date":"0001-01-01","id":37,"permalink":"/categories/","summary":"","tags":[],"title":"Categories"},{"content":"","date":"0001-01-01","id":38,"permalink":"/contributors/","summary":"","tags":[],"title":"Contributors"},{"content":"","date":"0001-01-01","id":39,"permalink":"/tags/","summary":"","tags":[],"title":"Tags"}] \ No newline at end of file