Skip to content
This repository has been archived by the owner on Nov 19, 2020. It is now read-only.

simple app to use for POC purposes to test out running agents in containers

License

Notifications You must be signed in to change notification settings

vmware-archive/secret-agent

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

9 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

secret-agent is no longer actively maintained by VMware.

#secret-agent a POC to try out various approaches for embedding a java agent in a continer alongside a pushed app.

##goals

  • language agnostic, the pushed app can be in any supported language
  • agent should be private to the container, not accessible from the outside
  • no special work needed by the pushed app to make use of the agent
  • minimally invasive to cf, the pushed app, existing procedures, etc.

##Approaches ###Custom buildpack ####Process

  1. Create a buildpack that will run the agent alongside an app in the same container.
  2. Put the agent out where we can get to it via wget
  3. Push a boot app using this buildpack, such as with the manifest below:
applications:
- name: passthrough
  memory: 1G
  instances: 1
  path: target/passthrough-1.0.0.jar
  buildpack: https://github.com/cf-platform-eng/basic-boot-buildpack

####Pros

  • It's simple
  • It works
  • We can control the jre used (to install a custom cert for instance, or use an alternate jre)

####Cons

  • Need a custom buildpack, and need to keep it up to date with CVEs
  • Assumes that the app being pushed is a boot app

###multi-buildpack Recommended by the Buildpacks team in NY, might be fully supported in the future.

####Process

  1. check out and build the multi branch of the secret agent. It is configured so that the agent is not listening on the "usual ports and IP" (so it will not conflict with the passthrough and can't be reached fromoutside the container).
  2. Use the just-agent branch of the custom buildpack created above: it is set to run just the agent.
  3. copy the passthrough jar file and the multi-buildpack.yml file to a new, empty temp directory
  4. from the new temp directory do a cf push
cf push passthrough
  1. Validate that the passthrough is able to cummunicate with the agent
curl -i http://passthrough.your.domain/hello

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Date: Fri, 16 Dec 2016 14:44:13 GMT
X-Vcap-Request-Id: 255cdcd7-cd29-4d17-4313-ca2bfe074f4a
Content-Length: 37

{"hello from 10.254.0.50":2147483647}

The "hello" response is coming from the agent, proxied by the passthrough.

####Pros

  • Multi-builpack is supposed to be the officially supported way to do this going forward

####Cons

  • Not supported yet
  • Need a custom buildpack, and need to keep it up to date with CVEs
  • Is not "the usual way to push apps"

###meta-buildpack A more lightweight approach?

###Process

  1. Clone the meta-buildpack project
  2. Modify our custom buildpack to make it a decorator
  3. Run the scripts

####Pros

  • More lightweight than the multi-buildpack approach
  • Decorator might be easier to deal with than a full-blown custom buildpack

####Cons

  • Need to install multi-buildpack and place it at the top of the buildpack stack
  • An experimental approach, may or may not be mainstreamed in the future
  • Pushing a decorator means that all apps will be decorated? Or just certain apps? How to control?

About

simple app to use for POC purposes to test out running agents in containers

Resources

License

Security policy

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages