Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(adr):Add an option to use Caddy instead of Nginx #1360

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 79 additions & 0 deletions docs_src/design/adr/0028-Caddy-Web-Server-as-option.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
# Caddy Web Server as option

## Submitters
- Miguel Herrnsdorf

## Changelog
<!--
List the changes to the document, incl. state, date, and PR URL.
State is one of: pending, approved, amended, deprecated.
Date is an ISO 8601 (YYYY-MM-DD) string.
PR is the pull request that submitted the change, including information such as the diff, contributors, and reviewers.

E.g.:
- [approved](URL of PR) (2022-04-01)
- [amended](URL of PR) (2022-05-01)
-->

## Referenced Use Case(s)
<!--
List all relevant use case / requirements documents.
ADR requires at least one relevant, approved use case.

Format:
- [UC Name](URL of use case)

Add explanations if the ADR is not addressing all the requirements of a use case.
-->

## Context

Currently there is only one option to use as webserver with Edgex, Nginx. This proposal is to add Caddy as web server alternative of Nginx, leveraging the many advantages and easy to implement usage that Caddy offers out of the box. Also, there are many plugins available for most common use, but you can write your own if you have a specific requirements. And since is written in Go and with extensibility in mind, plugins can compile as native code, in a way that cannot be broken during deployments or by system upgrades.
<!--
Describe:
- how the design is architecturally significant - warranting an ADR (versus simple issue and PR to fix a problem)
- the high level design approach (details described in the proposed design below)
-->

## Proposed Design

A flag should be passed to let the system know that the user wants to use Caddy as a reverse-proxy instead of Nginx (like NATS). If flag is used, a new Caddy container will be created instead of the Nginx coantainer.
herrdragon marked this conversation as resolved.
Show resolved Hide resolved
<!--
Details of the design (without getting into implementation where possible).
Outline:
- services/modules to be impacted (changed)
- new services/modules to be added
- model and DTO impact (changes/additions/removals)
- API impact (changes/additions/removals)
- general configuration impact (establishment of new sections, changes/additions/removals)
- devops impact
-->

## Considerations

Full Caddy features can found [here](https://caddyserver.com/features)
herrdragon marked this conversation as resolved.
Show resolved Hide resolved
<!--
Document alternatives, concerns, ancillary or related issues, questions that arose in debate of the ADR. Indicate if/how they were resolved or mollified.
-->

## Decision
<!--
Document any agreed upon important implementation detail, caveats, future considerations, remaining or deferred design issues.
Document any part of the requirements not satisfied by the proposed design.
-->

## Other Related ADRs
<!--
List any relevant ADRs - such as a design decision for a sub-component of a feature, a design deprecated as a result of this design, etc.

Format:
- [ADR Title](URL) - the relevance
-->

## References
<!--
List additional references

Format:
- [Title](URL)
-->