runtime
runtime copied to clipboard
acorn-io
TLS: Support for user provided domains
This is NOT for on-acorn.io domains
This is for the case where user supplies their own cluster domain, or even more likely creates an app with the following publish flag:
-p myapp.mydomain.com:<app deatils>
Supporting this means installing and managing cert-manager and auto-creating the Certificate CRs if the app wants TLS
We arent going to install cert-manager. User expresses they want TLS. If we find the Certificate CR, then we program it
What's the proposal then for how cert-manager should be installed? Just manually in to the cluster?
I don't know your design goals, but this was feeling to me like "bring me a cluster, give me access, deploy your apps with easy commands". Darren just said in the Webinar:
This feels like "No knowledge of Kubernetes YAML required, FOOTNOTE: unless you want to use your own domain name and use TLS with it". Hopefully it's reconsidered, having Acorn install cert-manager for you unless already installed/available.
Ahhh, I took the wording of the issue to be almost like a "we won't be doing this", but I guess it's just pending, based on:
In the future, Acorn will provide built-in mechanisms to automatically provide certificates for each endpoint. Today, adding a certificate must follow the manual approach.
-- https://docs.acorn.io/running/certificates
@andyjeffries There's a balance we're trying to find the right line on between batteries-included (you just want a cert, I don't know or care about CertManager) and tolerable-for-cluster-operator-to-install. The more stuff we add to someone's cluster the more they worry about trying it, compatibility between versions issues, should it be cleaned up on uninstall, etc.
CertManager does a lot of stuff and we don't even actually need so one option we're considering is not requiring it at all by doing ACME dances in the controller instead. That's straightforward enough for single name http-01 challenges.
The part CertManager does do that's really useful is taking creds and talking to all the provider APIs for dns-01/wildcards. But we can maybe do a one-time setup _acme_challenge.yourdomain.com CNAME [your-cluster].on-acorn.io yourself step, and then with that we can manage a *.yourdomain.com wildcard without having any creds or provider-specific implementation.
Not requiring (or self-embedding the relevant parts of) cert-manager would be cool.
I definitely lean to the "I have a cluster, but want acorn to manage it as a kind-of/lightweight PAAS for me" camp.
I know about Kubernetes (as former CTO of Civo.com), but I don't want to deal with the minutia of it in my new job as it's not necessary for me.
Right now, our implementation plans in this area are as follows:
- Supply a wildcard cert for the on-acorn.io domain associated with the cluster. This will not use cert-manager. It will just use existing go-libraries in our acorn controller
- For easy cert-manager integration (for those that already have it), allow for the propogation of annotations from the acorn containers to the ingress we create. This solves a lot of use cases, one of which is automatic cert creation through cert-manager: https://cert-manager.io/docs/usage/ingress/#supported-annotations
- Revisit that last paragraph of Vince's and other possible solutions to see what we want to do.
Hello there. Acorn is not finding a TLS secret!? I just tried several times it is not working.
Acorn will automatically inspect each certificate in the Acorn namespace for one that can be used with my-app.example.com. If no TLS secret is found with that FQDN, it will be exposed on HTTP only.
acorn install --cluster-domain sbx.huma.com --ingress-class-name nginx --acorn-dns disabled
acorn run -n todo-app-acorn --publish todo-app-acorn-1.sbx.huma.com:server .
I have a TLS secrets that external secrets operator created from GCP SM.
$ k get secret sbx-huma-com-tls-secret -n todo-app-acorn-cd495f1f-791
NAME TYPE DATA AGE
sbx-huma-com-tls-secret kubernetes.io/tls 2 10m
- there is no .spec.tls section in the ingress
- I use external-dns so I need to put an annotation. "external-dns.alpha.kubernetes.io/hostname": "todo-app-acorn-1.sbx.huma.com" annotation
$ k get ing -n todo-app-acorn-cd495f1f-791 -o yaml
apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
acorn.io/targets: '{"server.todo-app-acorn.sbx.huma.com":{"port":8090,"service":"server"},"todo-app-acorn-1.sbx.huma.com":{"port":8090,"service":"server"}}'
apply.acorn.io/applied: H4sIAAAAAAAA/8RTwW7bOhD8lYc9S4rkZ7sRgR7anooCRQ+5VTmsyLUkhCIJcuU6EPjvBaUkjW0kPfa2JmeGs+PRDCMxKmQEMQMaYxl5sCYsP6X1phjsDaPviAMImBsI5I/kC7bK5uhcvqJCeyr6acRC2rEBMTfgrOcGxG1Zl9nKGiQ1INIMGaBz+rF4ecL+MuTz7vgAAgbD5A3qP7fHKvvv22DUx0/OfTWB0cg3NQyOBALO/b0HDg5lYrwLDFObS2uYTgwCIGYgPS1R3Q0jBcbRgTCT1hlobEmfB5h8vOnrEnTl5xkwosGOVBLxE72+eUr3+Y31L7pepcfQgwCJNW1UXWO5rwllTWpf3R7KUm52/2+Uwr0qy3q726YtLxVfGzxfJZdqW+8O1SH/UFeJGhzJlMJgOk8hfNEYwvdVznSDOUEGftIUQPycobeBryWrs15BBj2zS5oOuV+JLcoHMiodPqWQxkvbqYzL+TS25NdWxhizRQgE3MA63j26xPvh6TCcIN7HmL14+3vx/4nB+xQ1I09L5bRF9Rl1+kA8iDnG+DsAAP//e5YZReMDAAA
apply.acorn.io/owner-gvk: internal.acorn.io/v1, Kind=AppInstance
apply.acorn.io/owner-name: todo-app-acorn
apply.acorn.io/owner-namespace: acorn
apply.acorn.io/owner-sub-context: ""
creationTimestamp: "2022-08-22T20:05:18Z"
generation: 1
labels:
acorn.io/app-name: todo-app-acorn
acorn.io/app-namespace: acorn
acorn.io/managed: "true"
acorn.io/service-name: server
apply.acorn.io/hash: ca9e2d99a069eac9ed618f00c2532dda6d009454
name: server
namespace: todo-app-acorn-cd495f1f-791
resourceVersion: "21480806"
uid: 42579c35-6344-4d36-86f8-bc803ae75259
spec:
ingressClassName: nginx
rules:
- host: todo-app-acorn-1.sbx.huma.com
http:
paths:
- backend:
service:
name: server
port:
number: 8090
path: /
pathType: Prefix
- host: server.todo-app-acorn.sbx.huma.com
http:
paths:
- backend:
service:
name: server
port:
number: 8090
path: /
pathType: Prefix
I have a TLS secrets that external secrets operator created from GCP SM. $ k get secret sbx-huma-com-tls-secret -n todo-app-acorn-cd495f1f-791
It looks like you are creating the secret in the generated namepsace that acorn creates. For this auot-detect feature to work, you want to add the secret to the user-facing namespace (acorn by default).
I use external-dns so I need to put an annotation. "external-dns.alpha.kubernetes.io/hostname": "todo-app-acorn-1.sbx.huma.com" annotation
I didn't realize external-dns relied on an annotation being on the ingress. I am currently working a feature to support the addition of arbitrary user-defined labels and annotations to be added to the resources created by acorn. Should be out in the next week or two.
I didn't realize external-dns relied on an annotation being on the ingress. I am currently working a feature to support the addition of arbitrary user-defined labels and annotations to be added to the resources created by acorn. Should be out in the next week or two.
Here is link to its docs Annotate the Service with your desired external DNS name. Make sure to change example.org to your domain.
kubectl annotate service nginx "external-dns.alpha.kubernetes.io/hostname=nginx.example.org."
It looks like you are creating the secret in the generated namepsace that acorn creates. For this auot-detect feature to work, you want to add the secret to the user-facing namespace (acorn by default).
IMHO not intuitive at all. When I feed my TLS secrets to my operator, I create secrets in each namespace, because this allows to cover tenant per namespace case.
Annotate the Service with your desired external DNS name. Make sure to change example.org to your domain.
Roger that. Hopefully when the annotation feature lands, it will meet your needs.
IMHO not intuitive at all. When I feed my TLS secrets to my operator, I create secrets in each namespace, because this allows to cover tenant per namespace case.
I hear you. That just hits a chicken-and-egg problem of adding the secrets after acorn has created and deployed everything. We have another feature in the queue for being to tell acorn to create its k8s resources in a pre-defined/pre-created namespace rather than a generated one. When that feature lands, you'd be able to drop the tls secret into namespace X and then deploy deploy there.
That said, as the feature stands now, I think you can still might be able to achieve what you desire. You can have a user-facing "acorn" namespace per tenant, rather than just using the default acorn namespace. You'd need setup some RBAC to ensure each tenant can only create acorn Apps in their namespace and no others.
do Acorn want me to name a secret some way? It doesn't pick up my secret.
$ k get secrets -n acorn | grep tls
sbx-huma-com-tls-secret kubernetes.io/tls 2 6m28s
todo-app-acorn-tls-secret kubernetes.io/tls 2 3m20s
$ acorn apps
NAME IMAGE HEALTHY UP-TO-DATE CREATED ENDPOINTS MESSAGE
todo-app-acorn 04f157adf923 2 2 94m ago http://server.todo-app-acorn.sbx.huma.com | http://todo-app-acorn-1.sbx.huma.com => server:8090 OK
Or have to rm app and create again?
Can you provide a dump of the cert (not the private key). Like openssl x509 -in cert.pem -noout -text or the kubectl yaml output and just drop the key field?
@cjellick do you want to say what I was doing an unexpected way of deploying?
It should I put secrets for my workload into acorn or todo-app-acorn-486a834d-ac4
Acorn creates a bunch of secrets that are empty in the acorn namespace. Are they supposed to be filled? Than why do they have random suffixes? I got confused.
# acorn's
$ k get secrets -n acorn | grep opaq
todo-app-bucket-secret-pwd9h secrets.acorn.io/opaque 0 5m13s
todo-app-db-jv5h9 secrets.acorn.io/opaque 0 5m13s
todo-app-rc-secret-d79ps secrets.acorn.io/opaque 0 5m13s
# mine
denis@L560:~/huma/compose-operator-examples/examples/acorn/todo-app$ k get secrets -n acorn | grep Opaq
todo-app-bucket-secret Opaque 4 8m31s
todo-app-db Opaque 3 8m31s
todo-app-rc-redis-config Opaque 1 8m33s
todo-app-rc-secret Opaque 1 8m33s
containers: {
server: {
image: "ghcr.io/huma-engineering/compose-operator-examples/todo-app:0.3.0"
entrypoint: [
"uvicorn",
"app:fastapi_app",
"--host",
"0.0.0.0",
"--port",
"8090",
"--reload"
]
env: {
"MINIO_ACCESS_KEY": "secret://todo-app-bucket-secret/aws_access_key_id"
"MINIO_SECRET_KEY": "secret://todo-app-bucket-secret/aws_secret_access_key"
"BUCKET": "secret://todo-app-bucket-secret/bucket_name"
"MINIO_REGION": "secret://todo-app-bucket-secret/region"
"MONGO_URL": "secret://todo-app-db/connectionString"
"REDIS_URL": "secret://todo-app-rc-secret/redis_url"
"MINIO_URL": "s3.amazonaws.com"
"MINIO_SECURE": "true"
"MONGO_COLLECTION": "todo-app-db"
"SIGNED_URL_LIFE": "7"
"SERVICE_URL": ""
"SIGNED_URL_BASE": ""
}
ports: publish: "8090/http"
}
}
It looks for a match in the SANs against the hostname.
todo-app-acorn-1.sbx.huma.com should accept *.sbx.huma.com TLS cert.
tls:
- hosts:
- todo-app-acorn-1.sbx.huma.com
secretName: pp-star-sbx-huma-com-secret
```
I have some issue with external-dns in my test cluster. I will get back tomorrow, it is late night in my place.
Yeah, wild card support hasn't been added/tested. It is on the list of items to add.
Do Acorn v0.1.4 support one certificate/tls-secret for 2 dnsNames at the moment? Is it a case of not supporting TLS for default "container.app.domain"?
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: acorn-selfsigned-cluster-issuer
spec:
selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: todo-app-cert
namespace: acorn
spec:
secretName: todo-app-tls-secret
dnsNames:
- todo-app-acorn-1.sbx.huma.com
- server.todo-app-acorn.sbx.huma.com
issuerRef:
group: cert-manager.io
kind: ClusterIssuer
name: acorn-selfsigned-cluster-issuer
$ acorn update -p todo-app-acorn-1.sbx.huma.com:server todo-app-acorn
todo-app-acorn
denis@L560:~/huma/compose-operator-examples/examples/acorn/todo-app$ acorn apps
NAME IMAGE HEALTHY UP-TO-DATE CREATED ENDPOINTS MESSAGE
todo-app-acorn 04f157adf923 2 2 15h ago http://server.todo-app-acorn.sbx.huma.com | http://todo-app-acorn-1.sbx.huma.com => server:8090 OK
https://todo-app-acorn-1.sbx.huma.com/ is working, but https://server.todo-app-acorn.sbx.huma.com/ gives NET::ERR_CERT_AUTHORITY_INVALID
I want to try and reproduce this, you have the single cert with 2 DNS names.
On the ingress resource in the generated todo-app-acorn namespace, can you confirm the secret is not being added in both places?
Hey Bill @cloudnautique This my ingress
$ k get ing -n todo-app-acorn-ea8f1b90-143 -o yaml
apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
acorn.io/targets: '{"server.todo-app-acorn.sbx.huma.com":{"port":8090,"service":"server"},"todo-app-acorn-1.sbx.huma.com":{"port":8090,"service":"server"}}'
apply.acorn.io/applied: H4sIAAAAAAAA/8RTy27bMBD8lWLPlCP5BYtAD21PRYGgh9xqH1bk2hJCkQS5ch0I+veCUl62kaS33Fbc2eHsaNhDS4waGUH2gNY6Rm6cjeOncsHOGnfDGA7EEST0W4gUjhRm7LTL0PtsQsXqNKu7FmfKtVuQ/Ra8C7wFucnLXExTjaItyFSDAPTePMyer3B/LYXscLwHCY1lChbNS/dYiC+/Gqu/fvP+p42MVr3JYbElkHCu7z1w9KjSxLvA2FWZcpbpxCABBgEq0GjVXdNSZGw9SNsZI8BgRebcwKTjTV2XoCs9T4AWLR5IJ5LQ0evOo7tPd0y/6HqVGmMNEhSWNNdlifm6JFQl6XWx2ee5mq8Wc61xrfO8XK6WactLxtcCz1fJCDf7oirzrFgu0mj0pJILjT0EivGHwRhvJzp7aOwJBITOUAT5p4faRb6mLM5yBQJqZp84PXI9DVao7snqdPjoQiovZacwjuddW1GYUjkMgxiJQMINTOXdg09zvwPtmxMMu2EQz9o+Dv6nCNwJYPNiYqo+tPE/VtkllArEtxe5ZROzqZOpRZmvcF5ker1KWgRERu7G7BuH+jua9FIDyH4Yhn8BAAD//+V6MipsBAAA
apply.acorn.io/owner-gvk: internal.acorn.io/v1, Kind=AppInstance
apply.acorn.io/owner-name: todo-app-acorn
apply.acorn.io/owner-namespace: acorn
apply.acorn.io/owner-sub-context: ""
creationTimestamp: "2022-08-23T13:41:38Z"
generation: 15
labels:
acorn.io/app-name: todo-app-acorn
acorn.io/app-namespace: acorn
acorn.io/managed: "true"
acorn.io/service-name: server
apply.acorn.io/hash: ca9e2d99a069eac9ed618f00c2532dda6d009454
name: server
namespace: todo-app-acorn-ea8f1b90-143
resourceVersion: "22156880"
uid: 7df1f9a6-b7ff-4475-a901-42773a956468
spec:
ingressClassName: nginx
rules:
- host: todo-app-acorn-1.sbx.huma.com
http:
paths:
- backend:
service:
name: server
port:
number: 8090
path: /
pathType: Prefix
- host: server.todo-app-acorn.sbx.huma.com
http:
paths:
- backend:
service:
name: server
port:
number: 8090
path: /
pathType: Prefix
tls:
- hosts:
- todo-app-acorn-1.sbx.huma.com
- server.todo-app-acorn.sbx.huma.com
secretName: todo-app-tls-secret-c3905a21-d65
TLS secrets seems to be equal inside
$ k get secrets -A | grep tls
acorn todo-app-tls-secret kubernetes.io/tls 3 85m
todo-app-acorn-ea8f1b90-143 todo-app-tls-secret-c3905a21-d65 kubernetes.io/tls 3 83m
P.S. I switched to namespaced issuer:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: acorn-selfsigned-issuer
namespace: acorn
spec:
selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: todo-app-cert
namespace: acorn
spec:
secretName: todo-app-tls-secret
dnsNames:
- todo-app-acorn-1.sbx.huma.com
- server.todo-app-acorn.sbx.huma.com
issuerRef:
group: cert-manager.io
kind: Issuer
name: acorn-selfsigned-issuer
@denist-huma Here is what I tried, and it seems to be working as expected. Can you let me know if my setup is different from yours?
It looks like the info you last provided, Acorn is recognizing the appropriate certificate to use for each of the domain names. I wonder if this is more of a cert issue?
I have a simple Acornfile with two containers:
containers: web: {
image: "nginx"
ports: expose: {
"80/http"
}
}
I requested a cert with two dnsNames:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: registry-studio-cert
spec:
dnsNames:
- registry.studio-rd.cloudnautique.com
- telemetry.studio-rd.cloudnautique.com
issuerRef:
group: cert-manager.io
kind: ClusterIssuer
name: cloudflare-issuer
secretName: registry-tls-secret
I built the app and launched it:
acorn build -t cert-test .
acorn run cert-test -h
#
#Volumes: <none>
#Secrets: <none>
#Containers: web
#Ports: expose: web:80/http
#
acorn run -p telemetry.studio-rd.cloudnautique.com:web -p registry.studio-rd.cloudnautique.com:web cert-test
#late-resonance
acorn apps
#NAME IMAGE HEALTHY UP-TO-DATE CREATED ENDPOINTS #MESSAGE
#late-resonance cert-test 1 1 46s ago http://registry.studio-rd.cloudnautique.com | http://telemetry.studio-rd.cloudnautique.com | http://web.late-resonance.cert-test.local.on-acorn.io => web:80 OK
Here is my ingress:
apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
acorn.io/targets: '{"registry.studio-rd.cloudnautique.com":{"port":80,"service":"web"},"telemetry.studio-rd.cloudnautique.com":{"port":80,"service":"web"},"web.late-resonance.cert-test.local.on-acorn.io":{"port":80,"service":"web"}}'
apply.acorn.io/applied: H4sIAAAAAAAA/8RTwY7TMBD9FTTnOJtuGra1xAFuCAlx2BvpYWJP22gd29iTdqso/47cbrsEqLYnuE3sec9v3rwM0BGjRkaQA6C1jpFbZ+PxU7lg89bdMYYNcQQJQw2BNm3kcMgj97p1IuhcGddriz23P3rKletqkEMN3gWuQS6KrIZIYdcqqkHWsCfIAL03h/zyhNtbCmKzewIJrWUKFs3r7W6WvfvSWv3ho/efbWS06iqHxY5AgkEmESg6+1Zz9KgSQlFgwRT5WnPsG6GcZXpmkABjBirQ0a7HtqPI2HmQtjcmA4MNmamJ6P11bb83/VXTualDixvSIIFDP4G/uHx+Z0/Nn7NsMW5BwsPsoZyVxVqX5bLStFwvdFPeN7SYr8tCqUIX+h6XWKUxJ3S/ypsOIppmjVVVVEKV84SLnlTyIPSGIsjvA2xdTN4xGerojRBBBltmnwg88vZE0KB6IqvT4cuwqZwITLE7HvZdQyHlbxzH7MgBEu7gVD4efIJ8C7Run2FcjWN2kXdLxP+fuj01+dT4/BKT3DiFJndWnPf9r3WuMmDzuuxU3bzum3xfZRBJBeKvJ7lnkGATxelG6PmymuH7UtASk6oMIiP3xx/SONSf0CTfAshhHMefAQAA//9B7GkMBQUAAA
apply.acorn.io/owner-gvk: internal.acorn.io/v1, Kind=AppInstance
apply.acorn.io/owner-name: late-resonance
apply.acorn.io/owner-namespace: cert-test
apply.acorn.io/owner-sub-context: ""
creationTimestamp: "2022-08-23T15:23:42Z"
generation: 1
labels:
acorn.io/app-name: late-resonance
acorn.io/app-namespace: cert-test
acorn.io/managed: "true"
acorn.io/service-name: web
apply.acorn.io/hash: 7173130fd3395de9f8db32be84f30cc0d0d2a9a5
name: web
namespace: late-resonance-bbfa5505-c34
resourceVersion: "13534"
uid: 725e1c61-e8b7-4e0a-9d3d-9ed4bc97e0de
spec:
rules:
- host: telemetry.studio-rd.cloudnautique.com
http:
paths:
- backend:
service:
name: web
port:
number: 80
path: /
pathType: Prefix
- host: registry.studio-rd.cloudnautique.com
http:
paths:
- backend:
service:
name: web
port:
number: 80
path: /
pathType: Prefix
- host: web.late-resonance.cert-test.local.on-acorn.io
http:
paths:
- backend:
service:
name: web
port:
number: 80
path: /
pathType: Prefix
tls:
- hosts:
- telemetry.studio-rd.cloudnautique.com
- registry.studio-rd.cloudnautique.com
secretName: registry-tls-secret-d4951a63-e9a
status:
loadBalancer:
ingress:
- ip: 192.168.5.15
kind: List
metadata:
resourceVersion: ""
selfLink: ""
@cloudnautique Thank you, I think it works as expected.
- https://todo-app-acorn-1.sbx.huma.com/
- https://server.todo-app-acorn.sbx.huma.com/
Both return for Chrome: NET::ERR_CERT_AUTHORITY_INVALID, for Firefox MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. That is expected.
What I had before was due to browser's cache, https://github.com/acorn-io/acorn/issues/486#issuecomment-1224082048 is solved.
@cjellick The topic of this issue is the Acorn supporting TLS out of the box, so probably can't close yet until we merge the annotations? Or we keep going to provide something completely end to end.
@denist-huma I was able to verify that Wild Card certs do work as expected. From my previous example in https://github.com/acorn-io/acorn/issues/486#issuecomment-1224235479 I changed the cert to:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: registry-studio-cert
spec:
dnsNames:
- "*.studio-rd.cloudnautique.com"
issuerRef:
group: cert-manager.io
kind: ClusterIssuer
name: cloudflare-issuer
secretName: wc-tls-secret
The certificate secret was applied to the Ingress resource correctly.
I changed the dnsNames to *.cloudnautique.com and it correctly did NOT assign the cert secret to the ingress.
So it does appear wild card support is working.
Please let me know if you are still running into issues.
@ibuildthecloud thank you, following you I tried one more time. In my setup I if both the self-signed cert "todo-app-tls-secret" and my *.sbx.huma TLS secrets present in the "acorn" ns, then Acorn do a thing I don't get:
- it uses
*.sbx.humaTLS fortodo-app-acorn-1.sbx.huma.com - the self-signed cert "todo-app-tls-secret" for the
server.todo-app-acorn.sbx.huma.com
$ k get secrets -n todo-app-acorn-697a2486-a79 | grep tls
pp-star-sbx-huma-com-secret-a1c5d9fc-f76 kubernetes.io/tls 2 13m
todo-app-tls-secret-c3905a21-d65 kubernetes.io/tls 3 13m
$ k get secrets -n acorn | grep tls
pp-star-sbx-huma-com-secret kubernetes.io/tls 2 18m
todo-app-tls-secret kubernetes.io/tls 3 24h
I did acorn rm and acorn run again, no changes. Clear browser data, restart browser not helps.
@denist-huma the cert would need to be for *.todo-app-acorn.sbx.huma.com. Wild cards are only valid for one level.
how can I disable the publishing of server.todo-app-acorn.sbx.huma.com?
Change the ports: publish: "8090/http" to "ports: expose: "8090/http" or remove it completely from acornfile and supply at run?
acorn run -n todo-app-acorn --publish todo-app-acorn-1.sbx.huma.com:server .
We went back and forth on whether to also create the generated-name endpoint if you explicit set and endpoint. We ultimately decided to create it, but your concern makes sense. We'll change the behavior to not create a generated-name endpoint when you've explicitly set one.
Here's the tracking issue: https://github.com/acorn-io/acorn/issues/383
@cjellick Yes that makes sense. :+1: My concern is that acorn should not "make an offer one cannot refuse" :) (c) Godfather
This issue has a lot of history and went in a couple different directions. We do want to support out-of-the-box, no-cert-manager-needed issuance of certificates for user provided domains. That is tracked here: https://github.com/acorn-io/acorn/issues/206
While the other issue will be the primary tracking issue for this feature, I am going to keep this issue open as a "sibling" issue to that one and when that feature is completed, we will close both these issues.