[Fleet] Add support & test for passing in api token to Docker container to move a stand-alone Agent to be Fleet enrolled

[EricDavisX]

Test setup would be as follows:

• run the Elastic stand-alone docker container
• from cli, run the script to pass it in Fleet token
• verify it shows up in fleet

Note, it was broken in 7.10+ line for some time.

More details on the fix here:
elastic/beats#23155

[ruflin]

My use case here is that I want to run the Elastic Agent Docker container but Fleet and everything is already setup. To make sure the Elastic Agent enrolls into Fleet on startup, environment variables need to be passed in.

[mdelapenya]

My use case here is that I want to run the Elastic Agent Docker container but Fleet and everything is already setup. To make sure the Elastic Agent enrolls into Fleet on startup, environment variables need to be passed in.

If I understand correctly this use case, we are starting ES, Kibana and Package registry before the agent container is even created. Then we initialise Fleet using an API call, and then we create the container. It always worked this way. Is that what you expect @ruflin?

[ruflin]

@mdelapenya Almost. There is a small difference here. My guess is that the Fleet API so far was called twice, once through the separate API call and once when the Elastic Agent was started by the Container. This is the reason it still worked. But if you pass in only the enrollment key to the container, things broke (should be fixed now). The reason I assume CI does not test it that way exactly is because it seems it didn't break CI ;-)

[mdelapenya]

When we deploy an agent to fleet, we:

1. Create a Fleet token for the agent, using an API call
2. PreInstall: for centos and debian installers, we do not execute code. For Tar installer, we extract the tar file
3. Install: for centos and debian, we use the package manager (yum and apt) to local-install the packages. For Tar installer, we execute the enroll command for the agent using its enrollment token
4. PostInstall: for centos and debian installers, we call systemd to enable and start the linux service, and then execute the enroll command for the agent using its enrollment token. For Tar installer, we do not execute any code else.

[ruflin]

@mdelapenya Not sure we talk about the same thing. This issue is only related to Docker but your list above seems to be for the parts outside docker?

[mdelapenya]

@ruflin @EricDavisX sorry for the late response. We triaged this issue today, and we discovered we would need more information to make progress on it. IIUC, what we want here is:

• enroll a stand-alone agent (using official Docker image for the agent)
• run "A_COMMAND_WITH_FLAGS" in the agent
• check the agent is still enrolled in Fleet.

Is it correct? If so, what "A_COMMAND_WITH_FLAGS" stands for?

@EricDavisX I think this would be backed by a new scenario in the stand-alone feature file.

[EricDavisX]

@IgorGuz2000 this is a great test to tackle, can you research it for us? The elastic/fleet-server repo or on-line guides should have info about the commands available to pass in for the docker container usage.

One pre-condition to confirm is whether or not the Docker Container is the Fleet Server as well or if there is a separate entity we plan to use to enroll against. I'd suggest the latter, and either way it will take some small amount of support setup rework.

[IgorGuz2000]

This was fixed for some time. I was running Stand alone agent and it works. Agent appears in the Fleet. Also I added scenarios for the System Integration with stand-alone agent. I think we can close this issue.

[mdelapenya]

Hey, we are about to merge #2879, which adds back the scenarios for the stand-alone agent. They basically are the following:

Scenario Outline: Starting the <image> agent starts backend processes
  When a "<image>" stand-alone agent is deployed
  Then there are "2" instances of the "filebeat" process in the "started" state
    And there are "2" instances of the "metricbeat" process in the "started" state

Scenario Outline: Deploying a <image> stand-alone agent
  When a "<image>" stand-alone agent is deployed
  Then there is new data in the index from agent

Scenario Outline: Stopping the <image> agent container stops data going into ES
  Given a "<image>" stand-alone agent is deployed
  When the "elastic-agent" docker container is stopped
  Then there is no new data in the index after agent shuts down

Scenario Outline: Adding the process_summary System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "process.summary"
  Then "system/metrics" with "process.summary" metrics are present in the datastreams

Scenario Outline: Adding the core System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "core"
  Then "system/metrics" with "core" metrics are present in the datastreams

Scenario Outline: Adding the cpu System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "cpu"
  Then "system/metrics" with "cpu" metrics are present in the datastreams

Scenario Outline: Adding the diskio System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "diskio"
  Then "system/metrics" with "diskio" metrics are present in the datastreams

Scenario Outline: Adding the fsstat System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "fsstat"
  Then "system/metrics" with "fsstat" metrics are present in the datastreams

Scenario Outline: Adding the load System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "load"
  Then "system/metrics" with "load" metrics are present in the datastreams

Scenario Outline: SAdding the memory System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "memory"
  Then "system/metrics" with "memory" metrics are present in the datastreams

Scenario Outline: Adding the network System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "network"
  Then "system/metrics" with "network" metrics are present in the datastreams

Scenario Outline: Adding the process System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "process"
  Then "system/metrics" with "process" metrics are present in the datastreams

Scenario Outline: Adding the socket_summary System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "socket_summary"
  Then "system/metrics" with "socket_summary" metrics are present in the datastreams

Scenario Outline: Adding the uptime System Integration to an stand-alone-agent
  Given a "<image>" stand-alone agent is deployed
    And the stand-alone agent is listed in Fleet as "online"
  When the policy is updated to have "system/metrics" set to "uptime"
  Then "system/metrics" with "uptime" metrics are present in the datastreams