[Agent] Docker image for integration tests #16898
Conversation
|
Pinging @elastic/ingest-management (Project:fleet) |
x-pack/agent/.gitignore
Outdated
| @@ -1,6 +1,9 @@ | |||
| # agent | |||
| build/ | |||
| agent.dev.yml | |||
| cmd/agent/agent | |||
| cmd/agent/agent.yml | |||
| cmd/agent/fleet.yml | |||
There was a problem hiding this comment.
these are created when you build and run agent there
There was a problem hiding this comment.
i'm usually building latest in x-pack/agent/cmd/agent and enrolling to fleet. this produces some garbage i don't want to check in
There was a problem hiding this comment.
I usually use mage build:all at the root :)
There was a problem hiding this comment.
Maybe its would be better to have them defined in your local ignore?
| setup | ||
| enroll | ||
|
|
||
| exec {{ .BeatName }} run "$@" |
There was a problem hiding this comment.
I think there is a small problem here, for testing using a docker container this work great, the setup + enroll using credentials but in the normal scenario we would use an enrollment key and nothing else, no?
There was a problem hiding this comment.
yes this container serves testing first, to be usable in a normal use cases it needs some tweaking. i was thinking about different options such as using flags to determine if we're testing or not or setting env variable like SETUP_KIBANA or PERFORM_ENROLL to perform any additional steps. without variables it would just do run.
There was a problem hiding this comment.
I have mixed feeling here, having something quickly working and adding a bit more work to make it behave with enroll? Do you think it is a lot of work to add it now?
There was a problem hiding this comment.
no i dont' but i'm not sure about which approach to take. flags vs env vars vs something else i dont see
There was a problem hiding this comment.
I think environment variables is fine for first version, I prefer to have the functionality right and we can change the flags until we move to GA.
|
Updated with env variables, to make docker run (locally) everything for you with default usernames and paths you need to do: if you start container without any env vars, simple |
|
Works for me. |
|
Jenkins test this |
| @@ -160,7 +160,7 @@ shared: | |||
| <<: *agent_binary_spec | |||
| extra_vars: | |||
| from: 'centos:7' | |||
| user: '{{ .BeatName }}' | |||
| user: 'root' | |||
There was a problem hiding this comment.
@michalpristas @ph @andrewkroh @urso Just stumbled over this change. I wonder if this could become a problem or is ok?
There was a problem hiding this comment.
this one was done on purpose as agent needs root permissions, the specification here is used for agent only so no beat is affected
[Agent] Docker image for integration tests (elastic#16898)
|
backported in #17574 to have a working build |
… enable building the agent. (#17574) * Fix issue when building Agent snapshot and enable building the agent. (#16927) An extension in the generated files ("SNAPSHOT") was preventing us to correctly generate the agent artifact with the packaged metricbeat/filebeat. Fixes: #16908 (cherry picked from commit 62d3683) * [Agent] Fix installers (#17077) [Agent] Fix installers for snapshots (#17077) * [Agent] fixed mage package for agent (#17368) [Agent] fixed mage package for agent (#17368) * [Agent] Make default config OS agnostic (#17016) [Agent] Make default config OS agnostic (#17016) * [Agent] Docker image for integration tests (#16898) [Agent] Docker image for integration tests (#16898) Co-authored-by: Michal Pristas <michal.pristas@gmail.com>
Newly created container definition for agent enrolls to kibana first and then runs and waits for kibana to provide configuration.
Configuration uses variables to connect to services with fallbacks to localhost on standard ports. This enables you to spin up kibana/es and start agent in a container running