-
Notifications
You must be signed in to change notification settings - Fork 4
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
Conditional at Launch #32
base: main
Are you sure you want to change the base?
Conversation
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 avoid repeating questions/comments from my review of paketo-buildpacks/google-stackdriver#38, assuming whatever the resolution is there we will make this PR consistent.
Reading docs for https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service raised an additional consideration. I think in both this and the google-stackdriver PR we should be appending the metadata server host to the no_proxy
and NO_PROXY
environment variables at build time. The agents probably skip the proxy for the metadata service by default but our InAzure
and InGcp
functions won't unless we configure it.
e807a20
to
a0e3e31
Compare
Previously, a binding was required at build time in order to contribute the layers for the Application Insights components. We've started to think that requiring a binding during build is too onerous a restriction and instead environment variables should be used to indicate that a dependency should be contributed. The knock-on effect of this change is that we have to move a lot more of the conditional logic out to launch time including ensuring that if the binding doesn't exist _nothing_ is contributed. This change makes those updates to the buildpack's behavior. In additional, this includes a fix where the provided build plan wasn't exhaustive for combinations that a user need when using the buildpack. Signed-off-by: Ben Hale <[email protected]>
a0e3e31
to
2881082
Compare
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.
Again, I didn't repeat comments that I already made on paketo-buildpacks/google-stackdriver#38, I figured that if you accepted any of those suggestions we would make this implementation consistent.
# `gcr.io/paketo-buildpacks/azure-application-insights` | ||
The Paketo Azure Application Insights Buildpack is a Cloud Native Buildpack that contributes the Application Insights Agent and configures it to connect to the service. | ||
# `paketo-buildpacks/microsoft-azure` | ||
The Paketo Microsoft Azure Buildpack is a Cloud Native Buildpack that contributes Microsoft Azure agents and configures them to connec to their services. |
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.
The Paketo Microsoft Azure Buildpack is a Cloud Native Buildpack that contributes Microsoft Azure agents and configures them to connec to their services. | |
The Paketo Microsoft Azure Buildpack is a Cloud Native Buildpack that contributes Microsoft Azure agents and configures them to connect to their services. |
### Type: `MicrosoftAzure` | ||
|Key | Value | Description | ||
|---------------------|---------|------------ | ||
|`InstrumentationKey` | `<key>` | Azure Application Insights instrumentation key |
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.
|`InstrumentationKey` | `<key>` | Azure Application Insights instrumentation key | |
|`InstrumentationKey` | `<key>` | Azure Application Insights [instrumentation key][i] |
### Type: `dependency-mapping` | ||
|Key | Value | Description | ||
|----------------------|---------|------------ | ||
|`<dependency-digest>` | `<uri>` | If needed, the buildpack will fetch the dependency with digest `<dependency-digest>` from `<uri>` | ||
|
||
## License | ||
This buildpack is released under version 2.0 of the [Apache License][a]. | ||
|
||
[a]: http://www.apache.org/licenses/LICENSE-2.0 |
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.
[a]: http://www.apache.org/licenses/LICENSE-2.0 | |
[a]: http://www.apache.org/licenses/LICENSE-2.0 | |
[i]: https://docs.microsoft.com/en-us/azure/azure-monitor/app/create-new-resource#copy-the-instrumentation-key |
@@ -52,7 +56,8 @@ func (j JavaAgent) Contribute(layer libcnb.Layer) (libcnb.Layer, error) { | |||
if err := sherpa.CopyFile(artifact, file); err != nil { | |||
return libcnb.Layer{}, fmt.Errorf("unable to copy %s to %s\n%w", artifact.Name(), file, err) | |||
} | |||
layer.LaunchEnvironment.Appendf("JAVA_TOOL_OPTIONS", " ", "-javaagent:%s", file) | |||
|
|||
layer.LaunchEnvironment.Default(AgentPath, file) | |||
|
|||
file = filepath.Join(j.BuildpackPath, "resources", "AI-Agent.xml") |
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.
Not relevant to this PR but should we create an issue to provide build and or launch time configuration options that allow folks to change the settings in AI-Agent.xml
? I imagine this is something App Insights users may want eventually.
|
||
const ( | ||
NodeModule = "applicationinsights" | ||
NodePath = "BPI_AZURE_APPLICATION_INSIGHTS_NODE_PATH" |
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.
NodePath = "BPI_AZURE_APPLICATION_INSIGHTS_NODE_PATH" | |
AppInsightsNodePath = "BPI_AZURE_APPLICATION_INSIGHTS_NODE_PATH" |
I suggest making this more specific only because, when I saw the variable used below, I assumed we were setting a default for NODE_PATH
and was momentarily confused.
} else if g, ok, err := bindings.ResolveOne(bs, bindings.OfType("MicrosoftAzure")); err != nil { | ||
return fmt.Errorf("unable to resolve MicrosoftAzure binding\n%w", err) | ||
} else if ok { | ||
b = g |
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.
} else if g, ok, err := bindings.ResolveOne(bs, bindings.OfType("MicrosoftAzure")); err != nil { | |
return fmt.Errorf("unable to resolve MicrosoftAzure binding\n%w", err) | |
} else if ok { | |
b = g | |
} else if m, ok, err := bindings.ResolveOne(bs, bindings.OfType("MicrosoftAzure")); err != nil { | |
return fmt.Errorf("unable to resolve MicrosoftAzure binding\n%w", err) | |
} else if ok { | |
b = m |
assume the g
is a copy pasted shorthand for google?
e[fmt.Sprintf("APPINSIGHTS_%s", s)] = v | ||
if s, ok := l.Binding.Secret["InstrumentationKey"]; ok { | ||
l.Logger.Info("Configuring Azure Application Insights instrumentation key") | ||
return map[string]string{"APPINSIGHTS_INSTRUMENTATIONKEY": s}, nil | ||
} |
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.
Do we potentially want to fail or warn if there is no InstrumentationKey
in the binding?
context("RequireModule", func() { | ||
|
||
it("renders require module", func() { |
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.
context("RequireModule", func() { | |
it("renders require module", func() { | |
context("RequireModule", func() { | |
it("renders require module", func() { |
Previously, a binding was required at build time in order to contribute the layers for the Application Insights components. We've started to think that requiring a binding during build is too onerous a restriction and instead environment variables should be used to indicate that a dependency should be contributed. The knock-on effect of this change is that we have to move a lot more of the conditional logic out to launch time including ensuring that if the binding doesn't exist nothing is contributed. This change makes those updates to the buildpack's behavior.
In additional, this includes a fix where the provided build plan wasn't exhaustive for combinations that a user need when using the buildpack.