Hope a few people in here are familiar with JCAPS.
Coming from pure j2ee world, it is difficult to digest the deployment model that JCPAS offers.
While creating deployment profile, we need to map the resources (such as jdbc, webservice connector) to external systems. External systems are predefined with the target server ip, port, db name, credentials etc(in case of jdbc). So the problem is an EAR built for test environment can not be deployed to production environment.
In simpler applications we could store database/credentials etc on to property files and hence EAR built for UAT could be deployed to Production with out any change.
Is there a similar strategy available for JCAPS by which EARs built against an environment can be promoted to another seamlessly?
In JCAPS the Deployment Profile (DP) is still a generic layer;
1) as developper you configure your (dev) properties in the Connectivity Map (CM) and the Environment External Application (EA) inbound and outbound properties;
2) then you extract the configuration into a file :asadmin extract-caps-application-configuration myear.ear
3) and upload this file to your testing/prod Glassfish: asadmin import-caps-configuration --host %HOST% --port %PORT% --user admin --passwordfile ...\passwordfile caps-config
4) in Glassfish\Common Task\CAPS\Env and CM Override you adjust the properties according to the environment! (and restart the ear)
5) enjoy JCAPS efficiency [optional]
all this process is summarized in Application Configuration - JCAPS 6 screencast
After a few days of research, I could find relevant info at:
http://wikis.sun.com/download/attachments/38767325/JavaCAPS6+Application+Configuration.pdf?version=1&modificationDate=1225463856000 and http://wikis.sun.com/display/JavaCAPS/Application+Configuration and http://wikis.sun.com/display/JavaCAPS/Application+Configuration+Lab.
Posting here just in case anyone stumbles up on this page as a search result.
Related
Currently I have a VM running and installed the binaries needed for fabric-ca. I have a docker-compose file looking like this:
I have some questions regarding this:
the docker-compose file will create one container, if I want it for
more organizations, do I need to copy/paste this and change the port
number? (I don't want to use intermediate CAs).
When registering/enrolling an identity, it will override the default
materials because It will always put the materials from the new identity in /etc/hyperledger/fabric-ca-client. So when creating multiple
identities (orderer, peers, users etc..) how do I need to organize
them? What's the best practise?
In the image you can see that the server and clients are specified,
is this a good approach? Or should the client and the server be a
different container?
More than one CA in a Docker Compose file - you can look at the Build your first network tutorial in the Fabric Docs which has a 2 Org network and various configuration files including Docker Compose.
Combined client/server Container - This might be convenient for testing, but in a production scenario definitely not for Security and Operational Integrity reasons.
Overwriting Identities - the enroll command writes a tree of data to the location specified by the environment variable FABRIC_CA_CLIENT_HOME but you can use --home to redirect the tree to a different location:
fabric-ca-client enroll -u http://Jane:janepw#myca.example.com:7054 --home /home/test/Jane/
what is the use of sling run modes property in sling.properties file?
I have a osgi felix bundle that installed onto aem admin bundle console through aem cq5 package manager.
**
configuration properties of one of the bundle service is not available
unless I put the following line in cq5/config/sling.properties file.
sling.run.modes=author,sandbox why is this so ? what is the importance
of sling.run.modes ?
**
Thank you,
Sri
Run modes allow you to tune your AEM instance for a specific purpose; for example author or publish, test, development, intranet or others.
Exampe: For dev: sling.run.modes=author,dev
use of run mode is, example - i have a config.author.prod and config.author.dev in crxd/e. Based on the run mode instance, the OSGI Bundle will pick the corresponding config.author.dev or prod configuration settings defined in nt:unstructured and start working.
Ref: https://docs.adobe.com/docs/en/cq/5-6-1/deploying/configure_runmodes.html
Ref: https://helpx.adobe.com/experience-manager/kb/RunModeDependentConfigAndInstall.html
Define a respository-based configuration for a single instance
There are two ways to configure CQ5.
Configure the Apache Felix Web Management Console
The configuration on the Apache Felix Web Management Console (http://:/system/console/configMgr) is always specific for the current instance.
You can find a description in the documentation: http://dev.day.com/content/docs/v5_2/html-resources/cq5_guide_system_administrator/ch05s03.html
Repository-based configuration
It is also possible to store configuration in the CRX repository as nodes of nodetype sling:OsgiConfig.
For more information, see http://dev.day.com/content/docs/v5_2/html-resources/cq5_guide_system_administrator/ch05s02.html
With this method, it is possible to share configuration among several instances.
The name of these nodes must be equal to the Persistent Identity (PID) of the configuration (for example, the name of the service). If you look at http://:/system/console/config, you see these names listed as service.pid properties. These configuration nodes have to be child-nodes of nodetype nt:folder with a name starting with config followed with a dot. All the run-modes that the config applies to are also separated with a dot.
Examples: config.author, config.publish, config.author.dev, config.author.foo.dev, and so on.
I have Java Liberty Web Application on Bluemix. If I need to update it, the app becomes unavailable for a few minutes. Is it possible to update it without turning it off? For example deploy two applications and reroute to a second one one when first is being updated?
Yep. There best way of doing this currently is via the following steps.
deploy original application on myroute.mybluemix.net
make some code changes
deploy changed application on myroute2.mybluemix.net
map myroute.mybluemix.net to the changed application using cf map-route APP_NAME DOMAIN [-n HOSTNAME]. Original application now has myroute.mybluemix.net and the changed application now has myroute.mybluemix.net & myroute2.mybluemix.net. At this point traffic will be routed equally between the two application versions (assuming they have the same number of instances).
unmap myroute.mybluemix.net from the original application using cf unmap-route APP_NAME DOMAIN [-n HOSTNAME]. All traffic on myroute.mybluemix.net will now all be routed to the newer version.
delete original application using cf delete APP_NAME
(optional) remove myroute2.mybluemix.net using cf unmap-route APP_NAME DOMAIN [-n HOSTNAME]
This seems a bit long winded but it will achieve what you want.
This is known as a blue-green deployment, and there are several cloud foundry plugins which will do it 'automatically':
Bluemix's Active Deploy service
This is new function, so it's in beta at the moment. To make the service available, you can add it from the Bluemix service catalog to your space. If you're running cf locally, you'll need to install the plugin:
cf add-plugin-repo bluemix http://plugins.ng.bluemix.net/
cf install-plugin active-deploy -r bluemix
Once it's available (either with a cf plugin install, or the catalog configuration), and you have routes, you can do
cf push --no-route new-version
cf active-deploy-create old-version new-version
Cloud Foundry community-contributed plugin for blue green deployments
You can install this using
cf add-plugin-repo garage https://garage-cf-plugins.eu-gb.mybluemix.net/
cf install-plugin blue-green-deploy -r garage
Then, to push,
cf blue-green-deploy app_name --smoke-test <path to test script>
The smoke test part is optional, but a good idea.
I'm trying to figure out the correct way to architect a solution to automatically configure new Rails App servers.
I've looked at the chef-rails cookbook and it seems a little verbose. In our case we always deploy Nginx a certain way, always perform backups a certain way, etc, so much of the configuration would be redundant from one node definition to the next.
My goal is to be able to create a new Rails App server by defining just the following information.
wh_webhead "test_app" do
ssl :enable
backups :enable
passenger :enable
ruby_version 2.0.0
db_type :mysql
db_user "testuser"
db_pass "3207496r9w6"
nagios_ssl_string_match "login"
end
Then I would like Chef to perform the following actions:
Create user accounts
Setup box and install
Install Nginx w/wildcard SSL cert
Configure log rotation
Setup firewall rules to allow traffic to ports 80 and 443
Install Passenger and RVM with Ruby 2.0.0
Create Rails app dirs following template (e.g. /opt/local/test_app)
Create new database on MySQL server, grant access, and setup firewall rules
Create firewall rules for Nagios and configure Nagios to monitor:
port 80 for redirection to port 443
port 443 for HTTP 200 status
port 443 for the text "login"
Configure backups for app dir (e.g. /opt/local/test_app)
I'm already using the community cookbooks for Nginx, Nagios, Ufw, etc and have created recipes in a custom cookbook to configure Mysql and Nginx. There's just a lot of duplicate code from one app's Nginx/Mysql cookbook to the next.
What I'm struggling with is where to use Cookbooks, Recipes, LWRPs and Definitions to properly abstract this.
Should I put the default configuration for Nginx and Mysql in Definitions and then use those in recipes or create custom wrapper cookbooks with the defaults?
First, take a look at the application_ruby and artifact cookbook, both of which can automate these workflows for you.
I specifically enjoy using the artifact cookbook, as it provides a lot of flexibility, but the application_ruby cookbook has built-in support for Passenger, Unicorn and other tools you'd normally find in a Rails application requirements.
As for your question regarding Cookbooks, Recipes, LWRPs and Definitions I would definitely look at #sethvargo's answer at https://stackoverflow.com/a/21733093/747032. It provides a good guide on what to use when, from an employee at Opscode (now called Chef (the company)), and someone who is constantly involved in the Chef community and thus has excellent knowledge on this topic.
As far as my advice (which I'll keep concise):
Use LWRP's to wrap a lot of resources that are always called together, for example, we use an "AWS EBS" LWRP, to create, mount and format new EBS'.
Use recipes to call on all your LWRP's (both custom and public) and resources.
Don't use definitions, they are really deprecated by LWRP's in my opinion.
If I understand correctly the standard git deploy implementation with capistrano v3 deploys the same repository on all roles. I have a more difficult app that has several types of servers and each type has its own code base with its own repository. My database server for example does not need to deploy any code.
How do I tackle such a problem in capistrano v3?
Should I write my own deployment tasks for each of the roles?
How do I tackle such a problem in capistrano v3?
All servers get the code, as in certain environments the code is needed to perform some actions. For example in a typical setup the web server needs your static assets, the app server needs your code to serve the app, and the db server needs your code to run migrations.
If that's not true in your environment and you don't want the code on the servers in some roles, you could easily send a pull request to add the no_release feature back from Cap2 in to Cap3.
You can of course take the .rake files out of the Gem, and load those in your Capfile, which is a perfectly valid way to use the tool, and modify them for your own needs.
The general approach is that if you don't need code on your DB server, for example, why is it listed in your deployment file?
I can confirm you can use no_release: true to disable a server from deploying the repository code.
I needed to do this so I could specifically run a restart task for a different server.
Be sure to give your server a role so that you can target it. There is a handy function called release_roles() you can use to target servers that have your repository code.
Then you can separate any tasks (like my restart) to be independent from the deploy procedure.
For Example:
server '10.10.10.10', port: 22, user: 'deploy', roles: %w{web app db assets}
server '10.10.10.20', port: 22, user: 'deploy', roles: %w{frontend}, no_release: true
namespace :nginx do
desc 'Reloading PHP will clear OpCache. Remove Nginx Cache files to force regeneration.'
task :reload do
on roles(:frontend) do
execute "sudo /usr/sbin/service php7.1-fpm reload"
execute "sudo /usr/bin/find /var/run/nginx-cache -type f -delete"
end
end
end
after 'deploy:finished', 'nginx:reload'
after 'deploy:rollback', 'nginx:reload'
# Example of a task for release_roles() only
desc 'Update composer'
task :update do
on release_roles(:all) do
execute "cd #{release_path} && composer update"
end
end
before 'deploy:publishing', 'composer:update'
I can think of many scenarios where this would come in handy.
FYI, this link has more useful examples:
https://capistranorb.com/documentation/advanced-features/property-filtering/