Skip to content

Commit

Permalink
typos and some code fixes
Browse files Browse the repository at this point in the history
  • Loading branch information
jsladerman committed Oct 3, 2024
1 parent 809aec4 commit ef00907
Show file tree
Hide file tree
Showing 6 changed files with 32 additions and 17 deletions.
2 changes: 1 addition & 1 deletion pages/how-to/deploy/microservice.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ description: Deploying a basic microservice to a cluster managed by Plural

# Overview

Now that you have a few clusters up, you'll likely want to start deploying real workloads into them. This will show you a relatively basic usecase with an example repo we've created at https://github.com/pluralsh/plrl-cd-demo.git.
Now that you have a few clusters up, you'll likely want to start deploying real workloads into them. This will show you a relatively basic use case with an example repo we've created [here](https://github.com/pluralsh/plrl-cd-demo.git).

You will:
* add a new git repository to your Plural Console
Expand Down
2 changes: 1 addition & 1 deletion pages/how-to/deploy/pipelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ spec:
tag: latest # VERSION
clusterRef:
kind: Cluster
name: plrl-how-to-workload-00-prod # replace this with whatever you might have named your dev cluster
name: plrl-how-to-workload-00-prod # replace this with whatever you might have named your prod cluster
namespace: infra
```
Expand Down
2 changes: 1 addition & 1 deletion pages/how-to/deploy/pr-automation.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@ spec:
type: STRING
documentation: the name of this blob store (if using s3, this would become an s3 bucket name)
validation:
regex: "[a-z][a-z\-0-9]+"
regex: "[a-z][a-z-0-9]+"
- name: type
type: ENUM
documentation: the type of blob storage to provision
Expand Down
39 changes: 27 additions & 12 deletions pages/how-to/set-up/controllers.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ A very common problem a user will need to solve when setting up a new cluster is
* DNS registration - you can use externaldns to automate listening for new hostname registrations in ingress resources and registering them with standard DNS services like route53
* SSL Cert Management - the standard K8s approach to this is using Cert Manager.

`plural up` gets you 90% of the way there out of the box, you'll just need to configure a few basic things. We also provide a consolidated [runtime chart](https://github.com/pluralsh/bootstrap/tree/main/charts/runtime) that makes installing these in one swoop much easier, but you can also mix-and-match from the CNCF ecosystem as well based on your organizations requirements and preferences.
`plural up` gets you 90% of the way there out of the box, you'll just need to configure a few basic things. We provide a consolidated [runtime chart](https://github.com/pluralsh/bootstrap/tree/main/charts/runtime) that makes installing these in one swoop much easier, but you can also mix-and-match from the CNCF ecosystem as well based on your organizations requirements and preferences.

The tooling you'll use here should also generalize to any other common runtime add-ons you might need to apply, which are all optimally managed via global services and if the templating is done well, will require a very small set of files to maintain. Some of these concerns can be:

Expand All @@ -27,14 +27,14 @@ We're going to use our [runtime chart](https://github.com/pluralsh/bootstrap/tre
First, let's create a global service for the runtime chart. This will ensure it's installed on all clusters with a common tagset. Writing this to `bootstrap/components/runtime.yaml`

{% callout severity="info" %}
The global services will all be written to a subfolder of `bootstrap`. This is because `plural up` initializes a bootstrap service-of-services under that folder and so we can guarantee any file written there will be synced. Sets of configuration that should be deployed independently and not to the mgmt cluster ought to live in their own folder structure, which we typically put under `services/**`.
The global services will all be written to a subfolder of `bootstrap`. This is because `plural up` initializes a bootstrap service-of-services under that folder, so we can guarantee any file written there will be synced. Sets of configuration that should be deployed independently and not to the mgmt cluster ought to live in their own folder structure, which we typically put under `services/**`.

*Changes will not be applied until they are pushed or merged to your main branch that the root `apps` service is listening to.*
{% /callout %}

```yaml
apiVersion: deployments.plural.sh/v1alpha1
kind: ServiceDeployment
kind: GlobalService
metadata:
name: plrl-runtime
namespace: infra
Expand All @@ -51,7 +51,7 @@ spec:
name: infra # this should point to your `plural up` repo
namespace: infra
helm:
version: 4.4.x
version: x.x.x
chart: runtime
url: https://pluralsh.github.io/bootstrap
valuesFiles:
Expand All @@ -73,7 +73,7 @@ external-dns:
provider: aws
txtOwnerId: plrl-{{ cluster.handle }} # templating in the cluster handle, which is unqiue, to be the externaldns owner id
txtOwnerId: plrl-{{ cluster.handle }} # templating in the cluster handle, which is unique, to be the externaldns owner id
policy: sync
Expand All @@ -83,16 +83,29 @@ external-dns:
serviceAccount:
annotations:
eks.amazonaws.com/role-arn: {{ cluster.metadata.iam.external_dns }} # check terraform/modules/clusters/aws/plural.tf for where this is set
{% if cluster.distro == "EKS" %}
ingress-nginx:
config:
compute-full-forwarded-for: 'true'
use-forwarded-headers: 'true'
use-proxy-protocol: 'true'
ingress-nginx-private:
config:
compute-full-forwarded-for: 'true'
use-forwarded-headers: 'true'
use-proxy-protocol: 'true'
{% endif %}
```

You'll also want to modify `terraform/modules/clusters/aws/plural.tf` to add the `dns_zone` to the metadata, it will look something like this once complete:

{% callout severity="info" %}
Usually DNS is managed by systems that predate adoption of Plural and so we don't provision it by default. We often recommend users create subdomains and register them w/ their root domain using an NS record to give their k8s cluster a sandboxed scope to register their dns entries in.
Usually DNS is managed by systems that predate adoption of Plural, so we don't provision it by default. We often recommend users create subdomains and register them w/ their root domain using an NS record to give their k8s cluster a sandboxed scope to register their dns entries in.
{% /callout %}

```tf
local {
locals {
dns_zone_name = <my-dns-zone> # you might also want to register this in the module, or likely register it elsewhere. Just the name is sufficient.
}
Expand All @@ -108,7 +121,7 @@ resource "plural_cluster" "this" {
}
metadata = jsonencode({
dns_zone = local.dns_zone_name
dns_zone = local.dns_zone_name # reference the local variable we created above
iam = {
load_balancer = module.addons.gitops_metadata.aws_load_balancer_controller_iam_role_arn
Expand Down Expand Up @@ -172,7 +185,7 @@ spec:
namespace: kube-system
protect: true # protect prevents deletion in the UI, but also tunes the cluster drain behavior to leave this service in-place which can help w/ cleanup
helm:
version: "x.x.x"
version: "1.8.2"
chart: aws-load-balancer-controller
url: https://aws.github.io/eks-charts
valuesFiles:
Expand Down Expand Up @@ -216,6 +229,8 @@ spec:
tags:
role: workload
template:
name: cert-manager
namespace: cert-manager
repositoryRef:
kind: GitRepository
name: infra
Expand Down Expand Up @@ -249,7 +264,7 @@ securityContext:
The `runtime` chart does provision a `letsencrypt-prod` issuer using the http01 ACME protocol, which usually requires no additional configuration. It might be suitable for your usecase, in which case the following is unnecessary. We have noticed it's more prone to flaking vs dns01. Also it can only work on publicly accessible endpoints since it requires an HTTP call to a service hosted by your ingress.
{% /callout %}

This sets up IRSA auth to cert-manager to allow dns01 ACME cert validations to succeed using Route53. You'll then want to create another service to spawn the cluster issuer resources cert-manager uses, you can do this by adding a file in `services/cluster-issuer/clusterissuer.yaml`:
This sets up IRSA auth to cert-manager to allow dns01 ACME cert validations to succeed using Route53. You'll then want to create another service to spawn the cluster issuer resources cert-manager uses, you can do this by adding a file at `services/cluster-issuer/clusterissuer.yaml`:

```yaml
apiVersion: cert-manager.io/v1
Expand All @@ -258,7 +273,7 @@ metadata:
name: dns01
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/
server: https://acme-v02.api.letsencrypt.org/directory
email: <your email> # replace here
privateKeySecretRef:
Expand Down Expand Up @@ -305,7 +320,7 @@ git commit -m "setup our cluster runtime"
git push
```

or create a PR, approve it, and merge to have the global deploy to all your clusters.
or create a PR, approve it, and merge to have the global service deploy to all your clusters.

{% callout severity="info" %}
You might need to wait a minute or two for the system to poll git and realize there's a new change.
Expand Down
2 changes: 1 addition & 1 deletion pages/how-to/set-up/mgmt-cluster.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ There are two options, `shared` and `dedicated`.
* `dedicated` cloud instances get a dedicated k8s cluster and database, and are built to scale effectively infinitely. To use a `dedicated` instance, an enterprise plan is required, so please contact sales and we can get you set up as quickly as possible if that fits your use-case.

The UI should guide you through the entire process, once your console is up, you'll be greated with a modal explaining how to finalize the onboarding. You'll need to still create a small management cluster in your cloud to host the Plural operator and any cloud-specific secrets. This is to ensure your cloud is fully secured and allow you to use Plural Cloud without exchanging root-level cloud permissions. You'll do that by simply running:
a

```sh
plural up --cloud
```
Expand Down
2 changes: 1 addition & 1 deletion pages/how-to/set-up/workload-cluster.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ If it's not showing, navigate to the `apps` service, and you can filter on `PrAu

## **Create a Workload Cluster**

Now that that PR Automation is configured, we should be able to spawn our cluster seamlessly. The steps are:
Now that PR Automation is configured, we should be able to spawn our cluster seamlessly. The steps are:

* **Navigate to `https://{your-console-domain}/pr/automations`**
* **Click `Create a PR` on the `cluster-creator` Automation Row**
Expand Down

0 comments on commit ef00907

Please sign in to comment.