-
Notifications
You must be signed in to change notification settings - Fork 86
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
Dockerized standalone Fleet Server #2359
Dockerized standalone Fleet Server #2359
Conversation
internal/pkg/server/fleet.go
Outdated
if cfg.Fleet.Agent.Checkin { | ||
sm := policy.NewSelfMonitor(cfg.Fleet, bulker, pim, cfg.Inputs[0].Policy.ID, f.reporter) | ||
if f.standAlone { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am assuming by now that "check in" and "standalone" mode are two different things, but I wonder if there is any use case for running standalone with check in (maybe only for development?), or to run in agent without checkin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More about this in #2359 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think there is some value to support checkin at all in standalone, but for these we probably need to make a change in Kibana to remove the restrictions of having an healthy fleet server agent, I can make a PR that introduce that change with a feature flag if you need it for testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @nchaulet, registration + checkin was added just to get around the kibana restrictions.
If we wanted to release a true "stand-alone" server it should not even need to enroll itself
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can then fully remove standAloneSetup
and standAloneCheckin
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can make a PR that introduce that change with a feature flag if you need it for testing.
@nchaulet that would be great. I guess this would solve part of the "Add Fleet Server" UI Components in https://github.com/elastic/ingest-dev/issues/1530. Instead of using a feature flag we could maybe use the check mentioned there if it is already available.
fleet-server.yml
Outdated
@@ -3,12 +3,15 @@ output: | |||
elasticsearch: | |||
hosts: '${ELASTICSEARCH_HOSTS:https://localhost:9200}' | |||
service_token: '${ELASTICSEARCH_SERVICE_TOKEN}' | |||
ssl.ca_trusted_fingerprint: '${ELASTICSEARCH_CA_TRUSTED_FINGERPRINT}' | |||
# ssl.ca_trusted_fingerprint: '${ELASTICSEARCH_CA_TRUSTED_FINGERPRINT}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this mandatory now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default elasticsearch runs in https
@michel-laterman please take a look to this draft to check if I am going in the good direction 🙂 Thanks! |
@jsoriano won't it be best to have a new "standalone" config that will toggle the new |
We discussed this with @joshdover. We could use the internal docker registry and publish the container image under the After some quick searching in GH I noticed how it's done in endpoint-dev repo for some dockery-related builds, setting an NS (namespace) to |
Yeah, I guess this is related to my other question in #2359 (comment). It will depend on the use cases we support, if for all standalone Fleet Servers we want to disable the checkin, then we can have a single "standalone" config that also disables the checkin. But, currently we also have an
This is why, in principle, I considered to have this as an explicit setting. |
@alexsapran sounds good. There is a separate issue about publishing the image being added here. Let's keep the discussion about this there. It is #2352. |
Makes sense, thanks for the link, I was not aware of that other issue, will cross post my comment there. |
@@ -0,0 +1,22 @@ | |||
ARG GO_VERSION | |||
FROM golang:${GO_VERSION}-buster AS builder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we using this instead of the same image as we base https://github.com/elastic/fleet-server/blob/main/Dockerfile.build off of?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both Dockerfiles have different purpouses, Dockerfile.build
is used to build the release packages for all platforms, and writes the generated packages to the working copy. This one only builds the binary in the platform it is executed, without writing to the working copy, and from it builds the docker image.
I could make a common Dockerfile for both to import, but I think they wouldn't have so much common code. We would also need to somehow handle the different platforms here.
It would be good though to use here make release
, to ensure that we are building the same release artifacts in both cases.
I will give another thought to this. I am mainly using this Dockerfile now to have an image for testing on Kubernetes. We could have a more final Dockerfile later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have replaced the build command in the Dockerfile to use make release-linux/amd64
instead, so we build with the same options as other release builds.
We will have to revisit this if we support other OSs or architectures.
This pull request is now in conflicts. Could you fix it @jsoriano? 🙏
|
Opening for review. @michel-laterman @nchaulet please take another look. |
This is great! It would be nice to add the example command to start to the README. |
Looks great to me, I tested this locally and it worked well! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm; the only other thing I can think of is to add instructions in the readme's dev section on how to run Kibana so that you can run a stand-alone fleet-server.
// you may not use this file except in compliance with the Elastic License. | ||
|
||
//go:build !integration | ||
// +build !integration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nitpick) I don't think we need the // +
directives
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Removed from all files.
Added docs about building the docker image for standalone and about the experimental flag to be able to use the Fleet UI. @juliaElastic @michel-laterman please take another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for adding the commands to the README.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should make it very clear in migration.go that no new migrations should be added going forward. Even better if we make the application crash if a new one is added
Co-authored-by: Josh Dover <1813008+joshdover@users.noreply.github.com>
What is the problem this PR solves?
Allow to run Fleet Server standalone without check in in production builds.
How does this PR solve the problem?
After this,
fleet-server
only needs an Elasticsearch service account to start.How to test this PR locally
fleet-server -c ./fleet-server.yml -E output.elasticsearch.ssl.verification_mode=none -E fleet.agent.checkin=false -E output.elasticsearch.service_token=....
Or
make release-docker
, and use the built docker image in your docker or kubernetes environment.Design Checklist
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related issues