Open finda-yeongjo opened 5 months ago
i think i may have also ran into this issue. What do your listener rules look like? I had to manually edit the listener rule condition to accept '/*' as opposed to '/'. As this ingress is deployed via the Mattermost operator, after some time or a redeploy the listener rule reverts back and we see the 404 again. I still haven't worked out a way to specify the wildcard in the path via the Mattermost installation manifest file though...
is there a way to edit the path that the aws ingress controller uses via the mattermost installation?
is there a way to edit the path that the aws ingress controller uses via the mattermost installation?
Not at the moment, the path is static in the code.
thanks @fmartingr is there any chance this will be configurable any time soon? or at least made static to /* for instance
If what @0arko said is correct, I request that @fmartingr modify the "pathType" of the Mattermost ingress to "Prefix." Here are my ingress desire manifests that are working correctly and a capture of the current problematic Mattermost ingress. You will easily understand what I mean.
I'm not currently aware of the roadmap, but ideally we could allow customising the ingress in the Mattermost spec by adding the path
and pathType
fields. I'm going to update the issue title to reflect the actual issue. And of course pull requests are welcome.
@finda-yeongjo I'm facing this exact problem on the same stack. Have you found a fitting solution yet?
There is a workaround for anyone who tries to deploy the operator on AWS. Disabling the operator self deployed ingress in the installation yaml:
ingress:
enabled: false
and then applying a custom made ingress yaml:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
alb.ingress.kubernetes.io/ssl-redirect: '443'
alb.ingress.kubernetes.io/load-balancer-name: SOMETHING_YOURS
alb.ingress.kubernetes.io/group.name: SOMETHING_YOURS
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/scheme: internal
alb.ingress.kubernetes.io/backend-protocol: HTTP
name: mattermost-ingress
namespace: SOMETHING_YOUR_NAMESPACE
spec:
ingressClassName: alb
rules:
- host: SOMETHING_YOUR_HOSTNAME
http:
paths:
- backend:
service:
name: MATTERMOST_INSTALLATION
port:
number: 8065
path: /
pathType: Prefix
@itaizelther
I used the same method as you.
I disabled the ingress activated in the operator, and separately created and connected the ingress.
However, I think this way clearly does not meet the expectation of unified centralized management using the operator.
Original issue title: The server was deployed in a Kubernetes using an mattermost-operator and installation, but a 404 error is occurring.
Summary
The server was deployed in a Kubernetes using an mattermost-operator and installation, but a 404 error is occurring.
Steps to reproduce
deploy mattermost-installation with gitops(app of apps), argocd
Expected behavior
Deploy successful
Observed behavior (that appears unintentional)
Pod deploy success and health check success
There is no error logs
3.When accessing via the URL, a 404 error occurs.
Possible fixes
Since we are using the Mattermost container image, it is difficult to identify the issue at the code level.