Outpost Healthcheck CLI

[alexluong]

We should consider outpost healthcheck as a CLI command for health check as alternative to curl localhost:3333/api/v1/healthz.

Following up from this conversation

[fmvilas]

I'm taking this one if you haven't started yet.

[alexluong]

@fmvilas I was going to include it in v0.9.0 but I do think this is a really really good task for you to take on so you have a better understanding of the CLI itself. Please do proceed. I have a few ideas that I didn't elaborate on, would you like me to braindump here or would you prefer to discuss further during the PR?

[fmvilas]

Thanks! Please do share here so I have a better understanding of it.

[alexluong]

@fmvilas here's a rough intro, I think this can be its own contributing guide as well.

We ship Outpost as a few different binaries. The main ones are cmd/outpost, cmd/outpost-server, and cmd/outpost-migrate-redis. You should check out .goreleaser.yaml which builds the binary, then Dockerfile.goreleaser which copies the binary into the final Docker image.

When we run outpost serve, it will run the outpost-server binary, for example.

What I'm thinking is we should introduce outpost healthcheck as a CLI command. I think we should also delegate to outpost-server as I think the 2 commands are closely related.

After #558, every service (api, delivery, log) all starts an HTTP server that exposes /api/v1/healthz endpoint at PORT (or API_PORT). The healthcheck command should simply ping that endpoint and exit with the right exit code. I think healthcheck can potentially support some options like -port or -path, but it's really up to you whether it's useful or not.

This is basically what I have in mind. Hope this makes sense and let me know if there's anything you'd like me to elaborate.

[fmvilas]

Thanks, that's actually aligned with what I had in mind 👍

What I'm thinking is we should introduce outpost healthcheck as a CLI command. I think we should also delegate to outpost-server as I think the 2 commands are closely related.

They're related in that they're both about the API. However, one is a server and the other is a client. I'd keep the outpost health command separate for now in the CLI. If it ever grows into a bigger thing, it can be split into a outpost-client binary or similar.

After #558, every service (api, delivery, log) all starts an HTTP server that exposes /api/v1/healthz endpoint at PORT (or API_PORT). The healthcheck command should simply ping that endpoint and exit with the right exit code. I think healthcheck can potentially support some options like -port or -path, but it's really up to you whether it's useful or not.

Yeah, we don't actually have to implement much. This command should leverage the Go SDK to call the API and display the response nicely. I think it's helpful to support port, in case you're running it outside the container and want to point to a different port than the one it's running inside the container.