Date   
Spring Boot Choose Main Class #spring #springboot #java

Mrc0113
 

Hi, 

I have a Spring Boot project which has multiple main classes (Yes - I know not best practices, but I'm not able to easily change it). The project is being built by maven. 
Locally I was able to specify a "start-class" on the spring-boot-maven-plugin and that works to define which main I want to run, however when I push the app to PCF that doesn't seem to work. 
It looks like my app is using the java buildpack... Is there someway to specify the main class that I want to run in PCF?  Maybe by settings an environment variable or as part of the cf push command? 

thanks! 

Re: Error: argument "virbr0" is wrong: Device does not exist #cf

Steve Mitchell <steve.mitchell@...>
 

Thank you, Eric. I set out to build a proxy, security, web site integration test to post to StackOverflow about a login redirect problem that started after upgrading to Spring Boot 2, but I unexpected ran into problems registering with my discovery service on pcf dev. I was trying to add Spring Cloud Services, but that ate up more time than I expected, so I decided to step away and I will look at it again later with fresh eyes.

On Mon, Apr 15, 2019 at 4:48 PM Eric Malm <emalm@...> wrote:
Hi, Steve,

Sorry to hear you're having problems with CF Dev. I'd suggest that if you continue to have difficulties running it on Linux, you may want to file an issue on the main CF Dev GitHub repository at https://github.com/cloudfoundry-incubator/cfdev. I expect the team would appreciate the feedback, especially as it looks like the week-old v0.0.15 release is the first one to support running on Linux at all.

Best,
Eric Malm, CF Application Runtime PMC Lead

On Sat, Apr 13, 2019 at 12:44 PM Steve Mitchell <steve.mitchell@...> wrote:
To fix this problem I installed KVM (Kernel-based Virtual Machine) following these instructions: https://www.linuxtechi.com/install-configure-kvm-ubuntu-18-04-server/ I completed steps 1 - 3. I did not have to configure the network bridge (so far). CFDEV started at least. We'll see if I have networks issues once I start using it.



Confidentiality Notice: This message and any included attachments are from medZERO, Inc. and are intended only for the addressee(s). The information contained in this message is confidential and may constitute inside or non-public information under international, federal or state laws. Unauthorized forwarding, printing, copying, distribution or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by email. Thank you for your cooperation.

Re: Error: argument "virbr0" is wrong: Device does not exist #cf

Eric Malm <emalm@...>
 

Hi, Steve,

Sorry to hear you're having problems with CF Dev. I'd suggest that if you continue to have difficulties running it on Linux, you may want to file an issue on the main CF Dev GitHub repository at https://github.com/cloudfoundry-incubator/cfdev. I expect the team would appreciate the feedback, especially as it looks like the week-old v0.0.15 release is the first one to support running on Linux at all.

Best,
Eric Malm, CF Application Runtime PMC Lead

On Sat, Apr 13, 2019 at 12:44 PM Steve Mitchell <steve.mitchell@...> wrote:
To fix this problem I installed KVM (Kernel-based Virtual Machine) following these instructions: https://www.linuxtechi.com/install-configure-kvm-ubuntu-18-04-server/ I completed steps 1 - 3. I did not have to configure the network bridge (so far). CFDEV started at least. We'll see if I have networks issues once I start using it.

Re: Mapping ORGs and Space permissions via LDAP

Eric Malm <emalm@...>
 

Hi, Mark,

The CF community engaged in a serious effort in this domain for much of last year, in the incubating CF Perm project (https://github.com/cloudfoundry-incubator/perm). In the course of that effort, that team and the CAPI team discovered that while it was easy to integrate Perm with the authorization model for Cloud Controller's v3 API endpoints, it was nearly impossible to do so systematically for the v2 endpoints because of the complexity of their authorization model in CC.

Consequently, the CF Perm project has effectively been on hiatus while the CAPI and CLI teams work through their v3 API acceleration effort to implement replacements for the remaining v2 API endpoints in v3. Those teams have also published some information about their progress towards v3 in recent cf-dev topics, such as CC API v3 Proposals and the CC API v2 Deprecation plan.

Best,
Eric Malm, CF Application Runtime PMC Lead

On Mon, Apr 1, 2019 at 10:21 AM Mark Coumounduros <mcoumounduros@...> wrote:

Hello Cloud Foundry:

Just checking back on whether there are ways to control access to org or spaces using UAA scopes (i.e., mapping LDAP Groups to Cloud Foundry Orgs and/or Spaces).

I last posted to the community back in Feb 2017 and am hoping this feature is now enabled for end users (or forthcoming).  Cheers!

Re: Error: argument "virbr0" is wrong: Device does not exist #cf

Steve Mitchell <steve.mitchell@...>
 

To fix this problem I installed KVM (Kernel-based Virtual Machine) following these instructions: https://www.linuxtechi.com/install-configure-kvm-ubuntu-18-04-server/ I completed steps 1 - 3. I did not have to configure the network bridge (so far). CFDEV started at least. We'll see if I have networks issues once I start using it.

Error: argument "virbr0" is wrong: Device does not exist #cf

Steve Mitchell <steve.mitchell@...>
 

cf dev does not start on Ubuntu:
$  lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:    bionic

$ cf uninstall-plugin pcfdev
Plugin pcfdev 0.30.2 successfully uninstalled.
$ cf install-plugin -r CF-Community "cfdev"
Plugin cfdev 0.0.15 successfully installed.
CLI: 0.0.15
BUILD: 54 (35368e4)
$ cf dev start
Downloading Resources...
Progress: |====================>| 100.0%
Setting State...
Error: argument "virbr0" is wrong: Device does not exist

Cannot find device "virbr0"
Creating the VM...
Starting the VM...
Fetching VM Address...
FAILED
cf dev start: exit status 1

Re: CF now supports sidecars

Mike Youngstrom
 

This is great!  Nice job CAPI team!  Keep it coming!

Mike

On Fri, Apr 12, 2019 at 3:00 PM Scott Sisil <ssisil@...> wrote:
Hi CF Community,

In the latest release of CAPI we included support for application sidecars. This feature allows you to define a sidecar process that can run alongside another application process you have deployed to CF.  You can learn more here in our docs

This has been a limitation of the platform in the past and one reason customers would choose running an app on K8s vs CF.  If you are unfamiliar with the sidecar design pattern - this article provides a great overview.

Please note this release is very much an alpha version of the sidecar feature and we plan to continue iterating on this to support more use cases moving forward.

If you have any questions about using this new sidecar functionality or have a specific sidecar use case we are not addressing - we would love to chat.  Please reply to this email or reach out to the team on the #capi channel in CF Slack.

Thanks,

Scott Sisil
CAPI PM

Re: CF now supports sidecars

Chip Childers
 

This is really exciting Scott. Great to see it progressing!

-chip

On Fri, Apr 12, 2019 at 5:00 PM Scott Sisil <ssisil@...> wrote:
Hi CF Community,

In the latest release of CAPI we included support for application sidecars. This feature allows you to define a sidecar process that can run alongside another application process you have deployed to CF.  You can learn more here in our docs

This has been a limitation of the platform in the past and one reason customers would choose running an app on K8s vs CF.  If you are unfamiliar with the sidecar design pattern - this article provides a great overview.

Please note this release is very much an alpha version of the sidecar feature and we plan to continue iterating on this to support more use cases moving forward.

If you have any questions about using this new sidecar functionality or have a specific sidecar use case we are not addressing - we would love to chat.  Please reply to this email or reach out to the team on the #capi channel in CF Slack.

Thanks,

Scott Sisil
CAPI PM

CF now supports sidecars

Scott Sisil
 

Hi CF Community,

In the latest release of CAPI we included support for application sidecars. This feature allows you to define a sidecar process that can run alongside another application process you have deployed to CF.  You can learn more here in our docs

This has been a limitation of the platform in the past and one reason customers would choose running an app on K8s vs CF.  If you are unfamiliar with the sidecar design pattern - this article provides a great overview.

Please note this release is very much an alpha version of the sidecar feature and we plan to continue iterating on this to support more use cases moving forward.

If you have any questions about using this new sidecar functionality or have a specific sidecar use case we are not addressing - we would love to chat.  Please reply to this email or reach out to the team on the #capi channel in CF Slack.

Thanks,

Scott Sisil
CAPI PM

Re: CF Application Runtime PMC: UAA Project Lead Call for Nominations

Dr Nic Williams
 

Thanks Sree for leading the enormously important UAA project for so many years!

Nic

 


From: cf-dev@... on behalf of Eric Malm <emalm@...>
Sent: Friday, April 12, 2019 9:34 am
To: cf-dev
Subject: [cf-dev] CF Application Runtime PMC: UAA Project Lead Call for Nominations
 
Hi, everyone,

Sree Tummidi, the Project Lead for the UAA team within the Application Runtime PMC, has stepped down from the project. We thank her immensely for her many years of service as the UAA Project Lead, and for her enormous contributions to identity and security issues within the Cloud Foundry community. She will be missed tremendously.

The UAA team, based in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, April 22, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead

Re: CF Application Runtime PMC: UAA Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Pivotal is nominating Chao Wang for the UAA Project Lead in the Application Runtime PMC.

Chao has been working at Pivotal as a product manager on the UAA project for the past eight months. Before joining Pivotal, he worked at an incubation and investment firm on customer IAM, mobile payment and fraud detection. Prior to that, he immersed himself in various roles in identity and security products at Microsoft, including Azure AD, ADFS, OrgID, Azure ACS, and NAP, in Redmond, WA.

Please send any other nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, April 22, 2019.

Thanks,
Eric Malm


On Thu, Apr 11, 2019 at 4:34 PM Eric Malm <emalm@...> wrote:
Hi, everyone,

Sree Tummidi, the Project Lead for the UAA team within the Application Runtime PMC, has stepped down from the project. We thank her immensely for her many years of service as the UAA Project Lead, and for her enormous contributions to identity and security issues within the Cloud Foundry community. She will be missed tremendously.

The UAA team, based in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, April 22, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead

CF Application Runtime PMC: UAA Project Lead Call for Nominations

Eric Malm <emalm@...>
 

Hi, everyone,

Sree Tummidi, the Project Lead for the UAA team within the Application Runtime PMC, has stepped down from the project. We thank her immensely for her many years of service as the UAA Project Lead, and for her enormous contributions to identity and security issues within the Cloud Foundry community. She will be missed tremendously.

The UAA team, based in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member. Please send nominations directly to me or in reply to this message no later than 11:59 PM PST on Monday, April 22, 2019.

Also, if you have any questions about the role or the nomination process, as described in the CFF governance documents (https://www.cloudfoundry.org/governance/cff_development_operations_policy/), please let me know.

Thanks,
Eric Malm, CF Application Runtime PMC Lead

NOTICE: End of support for Ruby versions 2.2.x and 2.3.x after 2019-05-11

Elliott Shanks
 

The first release of the Ruby buildpack after May 11, 2019 will no longer include any versions of Ruby 2.2.x and 2.3.x. These Ruby versions are no longer supported upstream [1]. Please migrate your Ruby apps to supported versions of Ruby before that time.


Note: Unless you are manually specifying a version of Ruby for the buildpack to use, or you have customized your Ruby buildpack, no action is required.


[1] https://www.ruby-lang.org/en/downloads/branches/


Thanks,

Elliott Shanks, CF Buildpacks PM

REQUEST for REVIEW - Scope for CF-Deployment 8.0

Saikiran Yerram <syerram@...>
 

Good day everyone,

Let me first introduce myself. My name is Sai and I am the new PM on Release Integration team. I am super excited to be here and also about the upcoming major cf-deployment release.

I'd like to share and gather feedback on proposed scope of the next major release of cf-deployment. Please note that removal of cflinuxfs2 cannot be postponed, since Canonical will no longer support Ubuntu 14.04 LTS (Trusty) after April 2019.

This Google doc describes the high-level changes.


Anyone with the link above can review and comment. Please take some time to peruse it and comment directly within the doc when you have a moment.

Lastly, if you've got upcoming breaking changes for cf-deployment that Release Integration should be aware of, please bring them to my and the team's attention:
Best regards,

--
Saikiran Yerram
PM - CF R&D Release Integration

REMINDER CAB call for April live today @ CF Summit Room 116 @ 11a Philly time

Michael Maximilien
 

FYI... 

Same time 8a Pacific or 11a EST and also streamed on zoom.  Room 116 at the Philadelphia convention center.


So join remotely if you can or if you are at CF Summit but can’t make it to the room.

Also, no set agenda. Just open discussions.

See / zoom you soon. Best,


dr.max
ibm ☁ 
silicon valley, ca


Re: Buildpack deep dive questions...

José Riguera López
 

I have a kind of same issue as you trying to understand how a buildpack works and creating a new one. The golang library used in the official buildpacks has no documentation, so it makes really difficult starting from zero, specially if we are talking of something which should be a "helper".
I made a grafana buildpack with bash scripts (https://github.com/SpringerPE/cf-grafana-buildpack) which think it makes easy to understand what each step (the scripts in `bin` folder) are responsible for, and the argument parameters (folders) they get. Is specially important the correct usage of the caching folder to avoid downloading again and again the binaries (resources), because there are other examples on github I think they do not properly manage that part (ofc, the buildpack works but it downloads again and again the resources).

Jose,

El lun., 25 mar. 2019 a las 15:45, Cade Thacker (<cade@...>) escribió:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

-- 
--cade



--
José Riguera López <jriguera@...>

Re: Buildpack deep dive questions...

Tim Downey
 

Feel free to reach out in the #capi channel on the Cloud Foundry Slack and folks from our team would be happy to chat!

As I mentioned earlier, we're actively working on the MVP so it's very experimental and there's not much yet in the way of docs for it, but we're working on it! Don't mean to derail your immediate plans though, so I would recommend looking into Dan's suggestions for the near-term.

- Tim

On Tue, Apr 2, 2019 at 1:22 PM Cade Thacker <cade.thacker@...> wrote:
This is outstanding.  How can I get involved? I’d love to jump into that conversation with both feet and help!! 

We are looking to better control egress and offload app security on ingress.  

Specifically envoy.  

Cade


On Apr 2, 2019, at 12:38, Tim Downey <tdowney@...> wrote:

Hi Cade,

This won't necessarily help for your immediate needs, but wanted to share that the Cloud Controller (CAPI) team is actively working on experimental support for including user-specified sidecar processes within the app container.

For the MVP form of this you'll still need to find a way to include the sidecar executable with your app (either via a buildpack or including it with the app source), but it should provide an easier way to specify/view information about the sidecar processes via `/v3/sidecars`.


As I said, this is still under active development and very experimental, but we'd be interested in learning more about your use cases.

Stay tuned!

Tim Downey, CAPI Team

On Tue, Apr 2, 2019, 6:53 AM Daniel Mikusa <dmikusa@...> wrote:
On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan


Re: Buildpack deep dive questions...

Cade Thacker <cade.thacker@...>
 

This is outstanding.  How can I get involved? I’d love to jump into that conversation with both feet and help!! 

We are looking to better control egress and offload app security on ingress.  

Specifically envoy.  

Cade


On Apr 2, 2019, at 12:38, Tim Downey <tdowney@...> wrote:

Hi Cade,

This won't necessarily help for your immediate needs, but wanted to share that the Cloud Controller (CAPI) team is actively working on experimental support for including user-specified sidecar processes within the app container.

For the MVP form of this you'll still need to find a way to include the sidecar executable with your app (either via a buildpack or including it with the app source), but it should provide an easier way to specify/view information about the sidecar processes via `/v3/sidecars`.


As I said, this is still under active development and very experimental, but we'd be interested in learning more about your use cases.

Stay tuned!

Tim Downey, CAPI Team

On Tue, Apr 2, 2019, 6:53 AM Daniel Mikusa <dmikusa@...> wrote:
On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan


Re: Buildpack deep dive questions...

Tim Downey
 

Hi Cade,

This won't necessarily help for your immediate needs, but wanted to share that the Cloud Controller (CAPI) team is actively working on experimental support for including user-specified sidecar processes within the app container.

For the MVP form of this you'll still need to find a way to include the sidecar executable with your app (either via a buildpack or including it with the app source), but it should provide an easier way to specify/view information about the sidecar processes via `/v3/sidecars`.


As I said, this is still under active development and very experimental, but we'd be interested in learning more about your use cases.

Stay tuned!

Tim Downey, CAPI Team

On Tue, Apr 2, 2019, 6:53 AM Daniel Mikusa <dmikusa@...> wrote:
On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan


Re: Buildpack deep dive questions...

Daniel Mikusa
 

On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan