Shulou(Shulou.com)05/31 Report--

Cloud Foundry buildpack development deployment example analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Basic principles

The basic process of CF running an application is to unpack the application package published by the user, then take all your buildpack, match them with the package in the specified order, until you find the first buildpack that can run the code, and then unpack the buildpack into a package (that is, droplet) with the application code, generate the container according to the specified running environment parameters, throw the droplet in, and follow the startup command specified by buildpack. Start the application. In the above process, buildpack implements three steps:

The first step, detect: check to see if the current application package can be run with this buildpack, for example, java buildpack thinks it can run when it finds the WEB-INF path.

The second step, compile: blend the application package with the buildpack package, for example, put the java package in the tomcat application directory, and then replace some parameters, such as assigning the random port in the current dea to the tomcat instance.

The third part, release: start droplet, such as startup.sh running tomcat.

Any buildpack has a bin path with three scripts with specified names (detect, compile, release) (any script that dea's os can execute), and then the specific implementation logic is triggered from here. The following will take java buildpack as an example to introduce the development and use of buildpack through three practical requirements.

Custom buildpack updates the default time zone and coding requirements for java applications

International software use Greenwich mean time as the default time in the system, so the log we write or the system time obtained by program code (actually dea system time) is + 0000, and we need + 0800, of course, we can handle it from the code. But my users are upset. They say that my program needs to be tested locally. It's too messy. You have to deal with it for me.

The default code in tomcat should be utf8, but in some scenarios, such as the rest service running on tomcat, the message contains Chinese and cannot be received normally. The default tomcat is included in CF's java buildpack, so in order to solve this problem, you can use the following command to set it, but it's not cool after all, so it's more friendly to change buildpack directly.

Cf set-env appname CATALINA_OPTS "$CATALINA_OPTS-Dfile.encoding=UTF-8" solution

Java buildpack is written by ruby, so if it's not a change in principle, you can do it by opening the package, modifying the ruby code, and then compressing it. However, there seems to be some inexplicable problem with winrar. It will be a problem if you unzip and recompress it, but you can work if you drag the modified file of the same name directly to the window of winrar to replace it. In order to meet the two requirements of time zone and coding, the files that need to be modified are as follows:

At java-buildpack-offline-v#.#.#\ lib\ java_buildpack\ component\ java_opts.rb

Add two methods to the

# @ return [JavaOpts] + self+-Duser.timezone def add_timezone (value) self

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.