Currently I want to use (opscode) Chef to configure all our routes on our machines. Since I'm very lazy, I already searched on the internet for an ready-to-go cookbook but couldn't find anything. I know, that Chef has a feature to configure routes "https://docs.chef.io/resource_route.html", but this is not enough for our use-case. We have VMs in different placement zones (prod, preprod, dev) in MZ and DMZ with different gateways on each.
If I can't find a cookbook that can differentiate that, I need to write one by myself. My idea was to analyze the node-name via ruby and use a loop and the chef-route resource to create all routes.
if /_prod/ =~ Chef::Config[:node_name]
So my hope is, that somebody is already using chef to configure routes in a enterprise-size and can help me out or that the community provides me some ideas on developing the cookbook by myself
Your environment description (around chef particularly) is not really detailed, so I'll answer on how I see it:
Chef environments to locks cookbooks in the dev/QA/Prod (could be
extended to dev/dev DMZ/QA/QA DMZ/Prod/Prod DMZ , etc)
One wrapper (role) cookbook to set attributes like gateway, static routes per type of box or per group of routes you wish to set
A code cookbook containing the recipe using the attributes defined before.
Depending on the way you'll have one or many wrapper cookbooks on your node runlist. Making a change to a route (in a wrapper) will go through locking them in the corresponding environment.
For the routes management, maybe a wrapper per "zone" is the best idea if one of your zone match exactly one environment.
WARNING: This is an exemple based on my current environment and how I would do it, I do not actually use the code below.
For our infrastructure, we have 3 QA environments (too much) within the same security zone (vlan), so we need to change the routing with the apps lifecycle, it's where the locking mechanism comes handy to change part of the nodes routing and not the whole nodes in the zone.
For the cookbook (the point 3 above, let's name it 'my_routing_cookbook'), it's quite "simple"
In the attributes let's have:
default['sec']['default'] = { gw: '192.168.1.250', device: 'eth1' }
default['sec']['routes']['172.16.0.0/16'] = { gw: '192.168.1.254', device: 'eth0' }
default['sec']['routes']['10.0.0.0/8'] = { gw: '192.168.1.254', device: 'eth0' }
In the recipe:
route '0.0.0.0/0' do
gateway node['sec']['default']['gw']
device node['sec']['default']['device']
end
node['sec']['routes'].each as |r,properties|
route r do
gateway properties['gw']
device properties['device']
end
end
The default gateway could be in the route list, I just think it's easiest for non networking people to retain it's the default gateway like this.
For the point 2, each wrapper cookbook will depend on this one and set it's own attributes. Thoose cookbooks will have a default.rb just calling include_recipe 'my_routing_cookbook'
Hope it will help you getting started.
Related
I don't know if this is possible I have only been using chef for about a week and a half now, I can't seem to find anything on the internet about doing this. But basically we have the chef client installed on a image. Each image has a configuration script that is run when the image is setup for the first time to set up the computer name and other settings specific to its setup.
So what I need to have happen once the config script finishes is to have a node created with the node name as the name of the computer that was entered automatically, along with aslo adding it to a role so that these nodes can later be sorted and have the correct roles added. So that going forward each new node will be created as soon as the server is setup without human interaction.
The way you do this is with the validator key system. Basically in the image have Chef installed, and have the /etc/chef/client.rb configuration created and pointed at your Chef Server, but don't create the client.pem key. If that key doesn't exist, chef-client will look for a validation key and use that to self-register with the Chef Server (by default it uses the FQDN of the server as the node name, but you can have your last-mile script append node_name "whatever" to the client.rb if you want to use something else). The difficult bit of validator-based bootstraps is how to store, access, and manage that validator key. The lazy way would be to just include it in the image, but this raises some troubling security issues. Unfortunately the best approach will depend entirely on what kind of systems you are running on and what security infrastructure is available. Also don't forget to remove the validator key after the initial bootstrap, there is a recipe in the chef-client cookbook for this.
I need to install multiple iDempiere instances in one server. The customized packages are different in build and the db they are using. Is there any way to deploy both of it in one server and access like localhost:8080/client1, localhost:8080/client2 . Any help appreciated.
When I want to reference several application servers I need to copy the path of various installations
and change the database name and port of each application :
/opt/idempiere-server-production/ (on port 8080 for example) for production
And
/opt/idempiere-server-test/ (on port 8081 for example) for test
the way you said is not possible, because the idempiere server for webapp is known as
http://hostname:port/webui
Running multiple instances of idempiere on a single server is not too difficult.
Here is what you need to take care of:
Install the instances into different directories. The instances do not need to share any common files. So you are just fine making a full installation for each instance.
Make sure each instance uses its own data base. Use different names for the instance data bases.
Make sure the idempiere server instances use different tcp ports.
If you really should need to use a single port to access all of the instances you could use a http server like apache or ngnix to do define virtual hosts. Proxying or use of rewrite rules will then allow you to do the desired redirections. (I am using subdomains and apache mod_proxy to do the job)
There is another benefit to using subdomains for browser access: If all your server instances use the same host name the client browser will sometimes not be able to keep cookies from different instances apart, which can lead to a blocked session as discussed here in the idempiere google group.
Use different DB user names. The docs advise not to change the default user name Adempiere and this is ok for a single instance installation. Still if you use a single DB user for all of your instances you will run into trouble once you need to restore a database from a backup file. The RUN_DBRestore.sh will delete and recreate the DB user which is not possible when the user owns more than one DB.
You can run all of your instances as services in parallel. Before the installation of another instance rename the service script: sudo mv /etc/init.d/idempiere /etc/init.d/idempiere-theInstance. Of course you will need to do some book keeping work wth the service controller of your OS to ensure that the renamed services are started as desired.
The service controller talks to the iDempiere server via the OSGI console. For this to work without problems in a multi instance environment you need to assign a different telnet port number to each of the instances: in the editor of your choice open the file /etc/init.d/iDempiere. Find the line export TELNET_PORT=12612 and change the port number to something else.
Please Note:
OS specific descriptions in this guide are for Ubuntu 16/18 or Debian, if on another OS you need to do some research.
I have been using the described approach to host idempiere versions 5 and 6 for some time now and did not have any problems so far. Still make sure you do your own thorough tests if you want to go that route.
If you run into any problems (and maybe even manage to solve them) please report back to the community. (by giving your own answer to this question or by posting to the idempiere google group) Thanks!
You can have as many setups on your server as you like. When you run the setup to create your properties, simply chose other web ports for each installation. You also may need to slightly change the webservers configuration if they have some default ports.
Coming from a MAMP Pro background, I loved the ability to have a "base" folder (/Sites in this case), have all of my projects underneath it and set custom server names/aliases with it. With Vagrant, it looks like I can accomplish the name/alias part with vagrant-hostsupdater, but if I really did just want to have the Vagrant files in /Sites and then all of them use the same config, what's the best way to specify a subfolder disk location with those custom host names?
I'm most likely over-thinking this, have just been a sucker for GUI interfaces and would love to know how to accomplish this. Thanks as always!
Clarification
What I'm used to
I used to use MAMP Pro, which allows you to setup custom host additions with their GUI interface. So, within my ~/Sites directory, I have several different projects going on, all in subfolders. The screen shot below shows how I can set a server name and specify a disk location, all from this central location.
What I'd like to do with Vagrant
Now I do know of (and used vagrant-hostsupdater), but what I was wondering is if I can set my Vagrant file in my ~/Sites directory (which is kind of like the root of the server; since all of my projects require the same setup) and then have individual host names setup for each project - so instead of having to access a subfolder like local.dev/project-1 or local.dev/project-2 I could setup server names such aslocal.project-1.comandlocal.project-2.com` from within that top-level Vagrant file and specify the subfolder it should attach that rewrite rule too.
The reason I'd like to do this is so I only have to run one vagrant up and I can then access all of my projects from one Vagrant instance as well as only keep track of one Vagrant file. Thanks!
You need to tell vagrant what hostnames you would like to use.
Directory based hostnames
Assuming you set you would like to set your hostnames based on the directory name; you can get all of the hostnames with ruby and pass them to the hostsupdater configuration.
SITES_DIR = "~/Sites"
config.hostsupdater.aliases = Dir["#{SITES_DIR}/*/"].map { |d| d.chomp('/') }
Configuration based hostnames
Alternatively you can mock up some sort of configuration that is desirable to you and what you are trying to do and evaluate/process it in ruby within the Vagrantfile.
I have an rspec testsuite that I use to test our internal and public facing API. Usually all I have to do to test the service is setup my parameters (e.g test urls) and from there the tests connect to the required service and do their thing.
My question is, how to I get ruby to honor my host file entries? In this specific scenario I'm trying to hit our pre-live servers, which use the same urls as our live environment, but obviously are on an entirely different IP cluster.
Unless you are doing some very low-level stuff, Ruby will not perform DNS name resolution by itself, it will simply call the appropriate OS API. So, you need to figure out how to configure your operating system to use a local hosts file.
Is there any way in topshelf to run multiple host in one executable?
// Create hosts
var h1 = HostFactory.New (...); var h2 = HostFactory.New (...)
// Start hosts
in one application Runner.Run (h1, h2);
Edit
Solved with threads. But not sure if it is safe...
new Thread (()=>Runner.Run (h1));
new Thread (()=>Runner.Run (h2));
From Topshelf docs:
You can only have ONE service! As of 3.x Topshelf the base product no
longer support hosting multiple services. This was done because the
code to implement was very brittle and hard to debug. We have opted
for a simpler and cleaner base product. This feature will most likely
come back in the form of an add on nuget.
Note: This is only valid for pre-3.0 version of Topshelf. In 3.0 this was removed and is being replaced with other methods of hosting multiple services.
There is no way to run multiple hosts. Starting a host blocks execution, does a whole bunch of stuff. You can register multiple logical services in a single host though.
https://github.com/Topshelf/Topshelf/wiki/Creating-a-service
return (int)HostFactory.Run(x => {
x.Service<Service1>({ ... });
x.Service<Service2>({ ... ]);
});
All logical services run under a single AppDomain. This may or may not be an issue. If you need to host them in separate AppDomains, we started working on shelving. http://topshelf-project.com/documentation/shelving/ As a warning, if you're going to start multiple logical services with the same type, make sure they have unique names when configured.