My development machine is different from my deployment/production servers in some ways that cannot be changed. (For example, my development machine has multiple versions of database servers running on different ports, while each production server has only a single version of the RDBMS running, each instance running on the default port.)
What techniques are available for configuring a Sinatra web application differently on one machine versus another? Ideally, answers would summarize multiple approaches, and highlight the one approach that has worked best for the respondent. Any file-based solutions should also (ideally) discuss how to handle this situation in the presence of a unified source control repository between both machines.
Note that this question/problem is orthogonal to configuring for development mode versus production mode.
One solution would be to load two configuration files: first, the main one (let's say, settings.rb), then a machine-specific one that would override necessary settings (settings-custom.rb).
Of course, since you have multiple machines, you have multiple configuration sets. In order to manage them easily, they could be named settings-$hostname.rb. Then you could simply symlink the appropriate file to settings-custom.rb. For example, on unix:
ln -s settings-`hostname`.rb settings-custom.rb
If you use source control, you can track all the configuration sets, and ignore settings-custom.rb (because it's only a symlink, and doesn't need to be tracked) -- with this method, you won't need to change any code between the machines.
Related
We have customers who deploy our application in WebSphere. Some use Linux others Windows. To minimize testing efforts we were looking to validate the possibility of just testing on Windows.
In theory, the risk is fairly low - the "write once, run anywhere" promise of Java holds up pretty well when you keep the app server and underlying JVM constant. Here are the general areas where (in my experience, at least) you'll need to be careful across the two platforms:
Batch/shell scripts - Not something you'd need to worry about in pure Java, but in the event you've got anything scripted outside the server process, this is something to be aware of. My guess, though, is that you wouldn't be considering skipping Linux testing if you had shell scripts to worry about.
Environment variables - Talking just about OS-level environment variables; anything you define within the server config should be safe.
File/path separators - Hopefully you're careful about using variables rather than hard-coding them so this won't be an issue.
File sorting - This is a sneaky one. Windows will sort files within a directory in a predictable order. Linux will not - it can depend on the vagaries of file system settings and maybe OS levels and whatnot. In a well-packaged app, this won't matter... but if you have any duplicate classes in WEB-INF/lib or EAR/lib, and they're not absolutely identical, it can break you. Make sure that you're not including multiple versions of any dependencies, because it's possible that the contents of those /lib directories will get pulled into the class path in different orders on different OSes (or even different systems with the same OS).
Best of luck!
I would add to #Jarid list the fact that, in Windows, file names are not case sensitive and this can cause problem depending of the technologies you are using in your applications (ie JSP file names, properties files etc). In this regards, if it works on Linux, it will work in Windows but the reverse may not be truw
It happend to us...
And also the underlying JDK may have different "behavior" and also differents "bugs" depending on the platform you use
Going to be working with a medium sized remote group on a large (but independent) project that will be generating many GB to TB of data.
To keep users from having to store 500GB of data on their personal machines, and to keep everyone in sync, we need a command-line/python utility to control selective syncing of dependencies on multiple operating systems: or at least osx and linux.
So example, someone who needs to work on the folder:
startrek/startrekiii
May require the folders:
startrek/nimoy/common
startrek/nimoy/[user]
startrek/shatner/common
startrek/shatner/[user]
but not:
startrek/startrekii, startrek/nimoy/[some_other_user], etc
From their command line (or a UI) they would run:
sync startrekiii
And they'd also receive startrek/nimoy/common, etc
likewise we'll have an unsync command that, as long as those dependent folders are not in use by another sync, will be unsynced and removed from the user's HD.
Of cloud sync/storage solutions, dropbox seems to offer the most granular control over this, allowing you to sync specific folders and subfolders - however from everything I can find this granular control is strictly limited to their UI.
We're completely open to alternative solutions if you have them, we just need something as easily deployable as possible and don't have the budget for Aspera or something to that effect.
Two other important notes:
Because of one very central part of our pipeline which pulls files
from those dependent folders (over which we have limited API
control), the paths need to be consistent on their respective
platform. So ~/Dropbox/startrek/nimoy can never be ~/Dropbox/startrek/startrekiii/nimoy
Many of the people using this will be artists and otherwise non-technical people, the extent of who's experience using csh or bash is for simple things like changing directories and moving files around.
Has anyone found a way to hack into Dropbox's selective sync, and/or know of a better alternative?
If there is a code base and many servers, how should I deploy the executable in multiple servers regularly? I need a script to do this
There are many system management tools. Chef is what we use, it is great but there is a bit of a learning curve. You may want to look into your OS's default package manager and distribute packages of your code base.
So I've been agonizing over embracing a deployment/configuration management tool like Chef or Puppet for a good long while. Not because I have any hesitation about them in general, but because I don't think they are a good fit for our specific scenario.
As far as I can see, these types of tools are targeted at frequent/wide-scale deployments, where you need to roll out software to 10s-1000s of systems. In our environment, we have a collection of ~25 different web services spread across half a dozen runtimes, with 1-8 deployments of each in production currently. Our big deployment problem is that each of the services has a different deployment story, and it's entirely manual, so it tends to be time consuming and error prone. Another wrinkle is that different instances in production may be different versions of the software, so we may need to concurrently support multiple deployment stories for a single service.
So I feel like we need something more like Ant/Maven/Rake, which is customized for each service. However, my experience with those is they are generally focused on local operations, and specific to a given language/runtime.
Is there a runtime-agnostic framework for describing and orchestrating building/testing/deployment in the manner I'm interested in?
I'm sure if I hit them long enough, I could get Rake or Puppet to do these for me, but I'm looking for something built for this purpose.
(Oh, and to make things worse, everything runs on Windows)
Thanks!
Here's another alternative you might want to consider: kwatee (I'm affiliated) is a free lightweight deploiement tool which besides having a web management interface can also integrate with ant (or maven or anything else with python CLI) to automate build & deploiement on dev/test environments for instance.
One of the nice things is the web configuration interface which make it pretty easy to quickly configure your deploiment stories, i.e. which software/version goes on which server. It's often necessary to setup different parameters in configuration files depending on the target server. For that you can "templatize" your packages using kwatee variable (similar to environment variables) which are configured with different values for each server.
Software must be registered in Kwatee's repository in the form of a folder of files, or an archive (zip, tar, tar.gz, bzip2, war) or a single file (e.g. an exe). Msi's are not supported. To deploy on windows kwatee needs the servers to have either telnet/ftp or ssh/scp (there are free tools out there).
Imagine you're going to manage a number of servers with a number of different services that's used by a number of people. Now say you want to reconfigure or replace some software on one of those servers. Obviously you don't want to work on servers that are in production.
If this was a code change, as a developer, I would make the change on my local development machine, test it locally and commit the change to a version control system. The changes could then be deployed in a staging environment, tested further and finally deployed in a production environment. It would also be easy for me to roll back, if necessary.
Generally, or specifically, how do you achieve this in system administration?
(The first thing that comes to mind is to use virtual machines and put virtual machine images in version control, but I'm sure there is a lot of literature and clever solutions I'm not presently aware of.)
Use chef or puppet to enforce machine configurations, and place their cookbooks and recipes under version control. Yes vms would make things easier but even physical server provioning can be controlled by kickstart or preeseed which can again be version controlled.