I am looking for extending WebSphere Liberty buildpack included in Bluemix with some third party libraries from our application architecture, so the size of EAR file will decrease a lot and cf push command will be more fast and agile. Is it possible?
I know there is a WebSphere Liberty buildpack open sourced at Cloudfoundry.org but as far as I know, it is not so powerful like the one included in Bluemix and we would loose some interesting features.
Thanks!
The Liberty buildpack you find on GitHub should be pretty similar to the one Bluemix uses especially in terms of features. Beta features are included and auto-configuration should work so in theory if you do cf push appName -b https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack.git -p myapp.war it should work the same way if you did cf push appName -p myapp.war.
If you want to modify the buildpack you can fork it and add the jars you want although I am unsure on the process for adding the jars. Maybe someone else can add an answer that points you in the right direction.
You can find an alternative buildpack for Websphere Liberty here. As you will notice, it is actually a CloudFoundry buildpack -- normally all of them will work in Bluemix. To use it, add a buildpack: line to your manifest.yml or a -b option to cf command line tool.
There is not much detail in your question as to what libraries or modifications you need, but this buildpack is in github and you can freely fork it and modify it. The buildpack prepares the runtime, and you should be able to add your own downloads in some hooks and replicate the directory structure you must be using locally. It is also very well documented, so you should find your way through the configurations if you are doing anything non-standard.
You are welcome to share your own new buildpack too!
If you want to be more efficient during the development cycle where you constantly push changes, you can try the 'development mode' support in the Bluemix Liberty buildpack. This allows you to push incremental file changes without even restarting the Liberty server (not to mention the whole application container, aka no cf push). See the doc here: https://www.ng.bluemix.net/docs/manageapps/eclipsetools/eclipsetools.html#incrementalpublish. You can also do remote debugging with development mode.
To customize a Liberty server in Bluemix, you can also use the server package command of a local Liberty server, and then cf push the generated zip.
See https://www.ibm.com/developerworks/community/blogs/msardana/entry/developing_with_bluemix_customizing_the_liberty_build_pack_to_add_your_configurations for details
That, of course, defeats your goal of smaller deployment times, but I wanted to add the possibility for completeness and to prevent someone from forking the buildpack without needing it.
Related
I'm currently developping a Spring Native application, it's building using paketo buildpack and generating a Docker image.
I was wondering if it's possible to customize the generated Docker image by adding third party tools (like a Datadog agent for example).
Also, for now the generated container image is installed locally, is it possible to send it directly in another Docker repo ?
I'm currently developping a Spring Native application, it's building using paketo buildpack and generating a Docker image. I was wondering if it's possible to customize the generated Docker image by adding third party tools (like a Datadog agent for example).
This applies to Spring Boot apps, but really also any other app you can build with buildpacks.
There are a couple of options:
You can customize the base image that you use (called a stack).
You can add additional buildpacks which will perform more customizations during the build.
#2 is obviously easier if there is a buildpack that provides the functionality that you require. In regards to Datadog specifically, the Paketo buildpack now has a Datadog Buildpack you can use with Java and Node.js apps.
It's more work, but you can also create a buildpack if you are looking to add specific functionality. I wouldn't recommend this if you have one application that needs the functionality, but if you have lots of applications it can be worth the effort.
A colleague of mine put this basic sample buildpack together, which installs and configures a fictitious APM agent. It is a pretty concise example of this scenario.
#1 is also possible. You can create your own base image and stack. The process isn't that hard, especially if you base it on a well-known and trusted image that is getting regular updates. The Paketo team also has the jam create-stack command which you can use to streamline the process.
What's more difficult with both options is that you need to keep them up-to-date. That requires some CI to watch for software updates & publish new versions of your buildpack or stack. If you cannot commit to this, then both are a bad idea because your customization will get out of date and potentially cause security problems down the road.
UPDATE
You can bundle dependencies with your application. This option works well if you have static binaries you need to include, perhaps a cli you call to from your application.
In this case, you'd just create a folder in your project called binaries/ (or whatever you want) and place the static binaries in there (make sure to download versions compatible with the container image you're using, Paketo is Ubuntu Bionic at the time I write this). Then when you call the cli commands from your application, simply use the full path to them. That would be /workspace/binaries or /workspace/<path to binaries in your project>.
You can use the apt buildpack to install packages with apt. This is a generic buildpack that you provide a list of apt packages to and it will install them.
This can work in some cases, but the main drawback is that buildpacks don't run as root, so this buildpack cannot install these packages into their standard locations. It attempts to work around this by setting env variables like PATH, LD_LIBRARY_PATH, etc to help other applications find the packages that have been installed.
This works ok most of the time, but you may encounter situations where an application is not able to locate something that you install with the apt buildpack. Worth noting if you see problems when trying this approach.
END OF UPDATE
For what it's worth, this is a common scenario that is a bit painful to work through. Fortunately, there is an RFC that should make the process easier in the future.
Also, for now the generated container image is installed locally, is it possible to send it directly in another Docker repo ?
You can docker push it or you can add the --publish flag to pack build and it will send the image to whatever registry you tell it to use.
https://stackoverflow.com/a/28349540/1585136
The publish flag works the same way, you need to name your image [REGISTRYHOST/][USERNAME/]NAME[:TAG].
For me what worked was in my build.gradle file (I'm using kotlin) I added this:
bootBuildImage {
val ecrRepository: String? by project
buildpacks = listOf("urn:cnb:builder:paketo-buildpacks/java", "urn:cnb:builder:paketo-buildpacks/datadog")
imageName = "$ecrRepository:${project.version}"
environment = mapOf("BP_JVM_VERSION" to "17.*", "BP_DATADOG_ENABLED" to "true")
isPublish = true
docker {
val ecrPassword: String? by project
publishRegistry {
url = ecrRepository
username = "AWS"
password = ecrPassword
}
}
}
notice the buildpacks part where I added first the base default oci and then the datadog oci. I also added on the environment the BP_DATADOG_ENABLED to true, so that it adds the agent.
I'm quite new in docker, and i'm wondering that when using spring-boot, we can easily build, ship and deploy the application with maven or gradle plugin; and we can easily add Load Balance feature. So, what is the main reason to use docker in this case? Is containerized really needed in everywhere? Thanks for the reply!
Containers helps you to get the software to run reliably when moved from one computing environment to another. Docker consists of an entire runtime environment: your application and all its dependencies, libraries and other binaries and configuration files needed for its execution.
It also simplifies your deployment process, reducing a hell lot of mess to just one file.
Once you are done with your code, you can simply build and push the image on docker hub. All you need to do now on other systems is to pull the image and run container. It will take care of all the dependencies and everything.
I am currently using JitPack to access my GitHub repository via Maven. I used to love JitPack, but their servers seem to be overwhelmed, they have terrible technical support, so all in all I'd like to stop using it. Does anyone have a suggestion on what is a good way to achieve a similar result? In other words, I'd like to be able to push a change to my GitHub repo, tag it, and be able to use it in my maven builds immediately.
My follow up question is: why is there even a need for a third party server to host these jars? Is there any way to simply have maven pull these github repos, compile them locally, storing cache in ~/.m2, and that's it. For most of my development effort, this would be enough. I find myself constantly at the mercy of JitPack's crappy servers and poor service that drive me crazy.
I've created the simple example from here, then packaged it using mvn package, and made an effort to deploy the result amp file as described here. But after restarting Alfresco I didn't see any changes. There were no new variants of workflow to choose. The java -jar alfresco-mmt.jar list <WARFileLocation> executing showed that modules org.alfresco.integrations.google.docs and org.alfresco.vti are installed in the chosen war but not a word about my helloworld workflow
UPD: I looked deeper through the tutorial and found that to add an activiti to the share u first need to add some other activiti to the alfresco. it is told there:
Open a command-line window and switch to
$TUTORIAL_HOME/workflow-tutorial-repo. Run mvn integration-test
-Pamp-to-war -Dmodule.log.level=debug. Your repo tier project will be installed and started on Tomcat running on port 8080. Open a new
command-line window and switch to
$TUTORIAL_HOME/workflow-tutorial-share. Run mvn integration-test
-Pamp-to-war -Dmaven.tomcat.port=8081
why is it so? I can't just deploy the only one project to the share but need to make a progect for the Alfresco first?
By the command you wrote you start repo. Since share and repo running on the same server they should run on different ports, so for share you need to provide another port, which is done by additional parameter: -Dmaven.tomcat.port=8081
UPD
#NikitinMikhail The quote you've added describes how to start share.
Alfresco consists of two projects (according to the maven sdk you use) which are repo and share.
Alfresco Share provides a rich web-based collaboration environment for managing documents, wiki content, blogs and more. Share leverages the Alfresco repository to provide content services and utilises the Alfresco Surf Platform to provide the underlying presentation framework.
In other words share is just separate project which communicates with repo and provides better user interface than repo.
I have a catalog of builds indexed by git revision stored on s3 by our CI server. Instead of performing a build at deploy time, I would like to just download a pre-built application, unpack it and go.
I'm trying to accomplish this with a custom buildpack, but in order to do so, I need for it find out which revision of the code is being compiled. Sadly (for me), I can not find this information anywhere in the environment.
It seems like this is something that ought to be discoverable somehow, but I'm completely flummoxed as to where.
You might want to take a look at the (not officially supported) heroku-anvil plugin, which includes the heroku release command to push externally created slugs to a Heroku app. It was originally designed for working with slugs created with Anvil, but should work for any TAR GZ, as long as it can be run on Heroku. For example you could do something like this:
$ heroku release https://s3.amazonaws.com/my-bucket/slugs-000.tgz -a myapp-staging
Releasing to myapp-staging.heroku.com... done, v42