Crate acme_proxy_server 

The server runtime: how a configuration becomes routers, and how those are served and rebuilt.

Startup is split on the socket boundary, which is what lets a test drive the whole path on an ephemeral port with its own shutdown future instead of a process signal:

• run binds server.bind_address, installs the SIGHUP handler, and hands the socket on. It is the whole of acme-proxy serve.
• serve_on validates the admin configuration and binds that socket too, when [admin] is enabled.
• serve_on_with does everything else — profile resolution, deduplicated signer backends, per-profile filters and validators, TLS, the job registry (every signer’s handlers, notification delivery and the six table sweeps, built by generation::job_registry_for), the runner draining it, and axum::serve with connect info attached.

That assembly is [generation::build_generation], and it is called again on every reload rather than only at startup — so the two cannot drift, and a subsystem added to one is added to the other by construction. What a reload may change, and what it refuses by name, is crate::reload’s to say; serve_on_with_reloads is where the two meet.

• profile — how a generation builds each ACME endpoint.
• assembly — what a generation hands its profiles, and what outlives it.
• generation — one generation built, then published: the reload policy.
• supervisor — the task that serialises reloads.
• sockets — the three listeners’ binds, plans and announcements.
• roles — which of acme, admin and worker this process runs.
• logging — the subscriber serve installs, and its reloadable filter.

What it serves sits below it: the endpoint itself is acme_proxy_protocol::profile::Profile, and the routers each listener serves, with their shared layers, are acme_proxy_protocol::router.

reload beside it is what a reload may change and what it refuses by name. An internal crate of the acme-proxy binary, published in lockstep with it and with no semver promise of its own.

Re-exports

pub use assembly::Assembly;

pub use assembly::GenerationParts;

pub use roles::ProcessRole;

pub use roles::RoleSet;

pub use sockets::check_metrics_config;

Modules

assembly

What one configuration generation hands its profiles (GenerationParts), and what outlives it (Assembly). What it dials through is acme_proxy_net::egress::Egress.

generation

One configuration generation: built and validated in full, then published in one uninterruptible run. Startup builds the first; a reload builds and publishes every later one.

logging

[logging] — resolving the configuration into an installed subscriber, and swapping it on a reload.

profile

How a configuration generation builds every Profile it mounts.

reload

Replacing a running configuration without restarting the process.

roles

Which of the server’s three jobs this process does.

sockets

The three listeners’ sockets: binding them at startup, planning a rebind on a reload, and announcing one that has come up.

supervisor

The one task that serves reload requests for the life of the process.

Functions

run

Binds the configured sockets and runs the server until a shutdown signal arrives: the whole of acme-proxy serve.

serve_on

Assembles and serves the application over an already-bound socket.

serve_on_with

serve_on with all three sockets supplied.

serve_on_with_reloads

serve_on_with, serving configuration reloads as well as requests.