Manually Managed EKS Service

[nickumia-reisys]

User Story

In order to deploy Solr reliably to cloud.gov, the Data.gov SSB Team wants to define the processes and logistics surrounding self-managing an EKS cluster to support our Solr deployments.

Acceptance Criteria

[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]

• GIVEN a new EKS cluster needs to be deployed
  WHEN a data.gov admin follows the process created here
  THEN an EKS cluster is deployed
  AND it is connected to the SolrCloud Broker
  AND a new SolrCloud service can be created.

Background

[Any helpful contextual notes or links to artifacts/evidence, if needed]

Security Considerations (required)

[Any security concerns that might be implicated in the change. "None" is OK, just be explicit here!]

Sketch

• Create an S3 Bucket on cloud.gov for terraform states
• Create a branch in datagov-brokerpak-eks to allow an S3 Backend for terraform states
• Provision an EKS cluster by manually running terraform init/apply in provision directory
• Create a binding for the EKS cluster by manually running terraform init/apply in bind directory
• Create a lot of documentation

[nickumia-reisys]

Tentative Design of EKS-Solr Deployment

[nickumia-reisys]

Full Initial Pass Complete!! Needs review, (only comment, don't approve please)

• [Don't Merge ... Ever] Manually Managed EKS-Solr Deployment GSA-TTS/datagov-brokerpak-eks#97

[nickumia-reisys]

Full Documentation on doing an EKS-Solr Deployment.

Active deployments will be tracked in google drive.

New scripts to streamline deployment:

• (bash) s3creds.sh sets up the S3 Backend for provisioning and binding.
• (bash) gather_provision_outputs.sh reconfigures the terraform provision outputs to terraform bind inputs.
• (python) package_k8s.py creates the json to create the UPS for the SolrCloud Broker