How to enable agent dependency caching

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

目的

Bamboo 6.2 introduces proxy support for agent dependency caching. That means, startup time of agents can now be decreased by enabling content caching on your reverse proxy. Once you enable it on the proxy side, Bamboo will display the confirmation information in the agent log file.

You'll see the following INFO message in the <BAMBOO_AGENT_HOME>/atlassian-bamboo-agent.log file when content caching is enabled:

INFO [WrapperSimpleAppMain] [ClasspathBuilder] Content caching is enabled for high performance bootstrap.

Otherwise, if it is not, you'll see the following WARN message:

WARN [WrapperSimpleAppMain] [ClasspathBuilder] Content caching is not enabled. This can cause performance impact on servers with high-tier licenses.

The dependencies we're talking about here are the JAR files the agent must download from the server during startup. So in order to speed up the agent startup time it's possible to cache plugin information at the proxy level. You won't have to change anything on the Bamboo side, only at the reverse proxy level. One important note is that you don't need to tell the proxy what items need to be cached, Bamboo will do this for you once content caching is enabled.

This should work with most reverse proxies as long as they support content/response caching. However, in this article, you'll find instructions on how to enable agent dependency caching for Apache HTTP Server and NGINX only.

ソリューション

Configuring Apache HTTP Server

Since Apache HTTP Server is not an Atlassian product, Atlassian does not guarantee to provide support for its configuration. You should consider the material on this page to be for your information only; use it at your own risk. If you encounter problems with configuring Apache HTTP Server, we recommend that you refer to the Apache HTTP Server Support page.

Note that any changes you make to the httpd.conf file will be effective upon starting or re-starting Apache HTTP Server.

Step 1: Enable mod_cache and mod_cache_disk in Apache HTTP Server

Load mod_cache and mod_cache_disk dynamically, using the LoadModule directive; that means un-commenting the following lines in the httpd.conf file:

LoadModule cache_module libexec/apache2/mod_cache.so
LoadModule cache_disk_module libexec/apache2/mod_cache_disk.so

Step 2: Configure Apache HTTP Server's caching features

Include the following Cache directives in the context (protocol type, virtual server, or location) for which you want to cache server responses:

<VirtualHost *:80>
	...
	
	CacheRoot  /etc/apache2/cache/
	CacheEnable disk /
	CacheDirLevels 2
	CacheDirLength 1
	CacheHeader on

</VirtualHost>
  • The CacheRoot directive defines the name of the directory on the disk to contain cache files. You must ensure that the user running the Apache service has read/write access to this directory.
  • The CacheEnable directive instructs mod_cache to cache urls at or below url-string and cache_typedisk to instruct mod_cache to use the disk based storage manager implemented by mod_cache_disk.
  • The CacheDirLevels directive sets the number of subdirectory levels in the cache. Cached data will be saved this many directory levels below the CacheRoot directory.
  • The CacheDirLength directive sets the number of characters for each subdirectory name in the cache hierarchy. It can be used in conjunction with CacheDirLevels to determine the approximate structure of your cache hierarchy.
  • When the CacheHeader directive is switched on, an X-Cache header will be added to the response with the cache status of this response.

Configuring NGINX

Since NGINX is not an Atlassian product, Atlassian does not guarantee to provide support for its configuration. You should consider the material on this page to be for your information only; use it at your own risk. If you encounter problems with configuring NGINX, we recommend that you refer to the NGINX Support page.

Step 1: Include proxy_cache_path to the top‑level http context

Include the proxy_cache_path directive in the top‑level http context; that means add the following line to the nginx.conf file:

http {
    ...
	proxy_cache_path /data/nginx/cache levels=1 keys_zone=bamboo_server:10m max_size=1024m inactive=20m use_temp_path=off;
}

The mandatory first parameter is the local filesystem path for cached content, and the mandatory keys_zone parameter defines the name and size of the shared memory zone that is used to store metadata about cached items.

  • You must ensure that the user running the NGINX service has read/write access to this directory.
  • In this example we'll name the cache bamboo_server and limit the amount of cached response data to 1024m.
  • Set inactive to 20 minutes. Cached data that are not accessed for over 20 minutes get removed from the cache regardless of their freshness.

Step 2: Include add_header and proxy_cache to start caching responses

Include the add_header directive using the 'X-Cache-Status' name and value '$upstream_cache_status'. This way the X-Cache-Status header will be added to the response with the cache status of the response. Include the proxy_cache directive in the context (protocol type, virtual server, or location) for which you want to cache server responses, specifying the zone name defined by the keys_zone parameter to the proxy_cache_path directive (in this case, bamboo_server):

server {
	...
	add_header           'X-Cache-Status' '$upstream_cache_status';
	location / {
    	...
    	proxy_cache           bamboo_server;
  	}
}

There are several other attributes you can add to tweak cache settings, as pointed out in the NGINX Content Caching documentation. This is highly customizable. However, as mentioned previously in this article, for remote agent content caching you just need to enable the content caching on the proxy and Bamboo will tell the cache what to store.

Testing agent dependency caching

The following cURL command will help you test whether caching is successful even before starting up an agent. You don't need to have an agent installed for the purpose of this test.

curl -v http://<BAMBOO_BASE_URL>/agentServer/bootstrap/content-cache-test

You should see X-Cache-Status HIT. Similar to the following:

< HTTP/1.1 200 OK
< Server: nginx/1.13.10
< Date: Fri, 30 Mar 2018 16:20:50 GMT
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 5001
< Connection: keep-alive
< X-ASEN: SEN-500
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Fri, 30 Mar 2018 16:20:07 GMT
< Cache-Control: public, max-age=30
< X-Cache-Status: HIT

This means the entity was fresh, and was served from cache. If you see MISS then the entity was fetched from the upstream server and was not served from cache.



最終更新日 2018 年 4 月 18 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.