Cert-manager: kick start manuals

Created on 16 Apr 2018  路  19Comments  路  Source: jetstack/cert-manager

Follow-up to https://github.com/jetstack/cert-manager/issues/399

Ok I am basically looking for a quick start like a "hello world" manual.

For example if one checks this repo https://github.com/gnab/remark and copies the snippet then one could start immediately.

When I read the documentation of the cert-manager repo it is clear how to install tiller and how to deploy the cert-manager using helm, but how to get a simple certificate up and running is unclear.

My suggestion is to have three manuals for Google Cloud Platform (GCP), Amazon Webservices (AWS) and Azure, e.g.:

In order to get cert-manager up and running on GCP:

  1. create k8s cluster
  2. deploy cert-manager using helm
  3. deploy simple spring boot app, e.g. hello world app (also using helm)
  4. create a dns name in gcp
  5. deploy ingress
  6. update dns (please wait 15 minutes to ensure that the dns has been updated
  7. test it and it should work

In summary, I am basically looking for a kick start, a helloworld example.

I am willing to create several PRs, but I need some pointers as I am struggling to get this working.

All 19 comments

+1. I read documentation but it's still not clear for me what should be done to make it work. For example, should I use spec.tls like in kube-lego or not?

spec:
  tls:
  - hosts:
    - echo.example.com
    secretName: echoserver-tls

Some examples directory also like in kube-lego (https://github.com/jetstack/kube-lego/tree/master/examples) will simplify everything :+1:

There has been some work around providing this sort of documentation (see #428, #412).

This site is available here: http://cert-manager.readthedocs.io/en/latest/

The page here is probably the right place to get started figuring out where the documentation is rough and what's missing.

I do think an opinionated walkthrough for "I host k8s and my domains on GCP/AWS" could be useful. The cluster doesn't have to be on the same provider as the dns records, but it's certainly easier to get started if you have to deal with fewer clouds.

I think many of the steps you suggest can be handled by linking to external documentation (e.g. cert-manager certainly shouldn't be writing content about how to deploy a k8s cluster; cert-manager shouldn't be writing docs about 'how to point nameservers at route53' -- aws already has that).

@Jokero I've just found out that you have to add spec.tls part to make the cert manager work with ingress-shim. And as the documentation already states, the name of the secret will be the same as the name of the Ingress, so you have to put the name of the Ingress in the spec.tls.hosts.secretName field. (I'm using cert-manager-0.2.9 chart.)

@novakg I tried with my custom secretName and it also works)

@Jokero @novakg Where did you define your DNS and where do you run k8s?

@Jokero Do you mean that the part of kube lego your were referring to should be replaced with the cert-manager part?

DNS is owned by namecheap (where I bought a domain; if you asked about it) and k8s provider is Google Kubernetes Engine.

Do you mean that the part of kube lego your were referring to should be replaced with the cert-manager part?

Might be made by analogy, yes. For me it's much easier to learn new k8s component based on some ready manifests and only then switch to helm package.

@jokero I will try the following

Create a domain in was

Clone the kube Lego project

Adjust the echo.domain example by changing the DNS name in echo to the domain that has been created in aws

Run the kube Lego commands on a GCP k8s cluster

An ingress will be created

Navigating to that domain will be green

What do you think of this approach? I have concerns regarding the combination of AWs DNS combined with gcp k8s

Once this works, I will run the cert manager helm example. Did you use a same approach as well? Or did I not understand it well?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale

/remove-lifecycle rotten

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

/remove-lifecycle stale

I assume that the issuers have to be deployed in the cert-manager namespace?

https://github.com/jetstack/cert-manager/blob/master/docs/tutorials/quick-start/index.rst#step-6---configure-lets-encrypt-issuer

Once I followed this https://github.com/jetstack/cert-manager/blob/master/docs/tutorials/quick-start/index.rst#step-6---configure-lets-encrypt-issuer and deployed the issuers in the namespace of the app, it works

We now have the let's encrypt quick-start tutorial which covers most of what you're asking for here. If you've got suggestions or improvements, it'd be great if you could open a PR against the document or otherwise open an issue with suggestions for different areas that could be improved 馃槃

Was this page helpful?
0 / 5 - 0 ratings