My Grails app is based on
Gradle with Grails 2.4.4,
Tomcat plugin 7.0.55,
and MySQL plugin(mysql:mysql-connector-java:5.1.29).
Do I need to install Tomcat on the server?
Do I need to install MySQL on the server?
Both Tomcat and MySQL are not installed on dev environment(on my PC), but it seems working.
Container
While all the other answers pointed out, that you need already a container (which of course is true) there is also the option to use one of the "standalone" plugins (like e.g. https://grails.org/plugin/standalone). This will package your app as a fat jar, where the container and your app are part of a jar, that you simply run by java -jar myapp.jar (of course your would integrate that into your regular startup scripts on the server).
This is in general no bad option, since many WAR-deployed apps don't need any of the full blown container features anyway and you would be able to configure everything in place for your workload and don't have to compromise for all running wars (or your ops team). On the downside, if there is a security problem etc. with the container you would have to roll a new jar.
/With grails 3, which uses Spring Bootstrap, this even is a default option, since the preferred way of deploying. Spring Boot 1.2 supports Tomcat, Jetty, and Undertow by default./
Database
You can use a MySQL from "somewhere" else. But this is nitpicking, since you really need a MySQL somewhere (BTW: you really should start using MySQL also for your dev env, or you will be in for a few surprises once you put your stuff over to production).
Also be aware, that you can also keep using your H2 (see your datasource config) with files. This is an OK option (that saves you from installing a DB server) for small amounts of data you are storing and also there are other free database servers like PostgreSQL.
Obviously you have to install mysql and tomcat on the server.
During development you run grails from console, so you dont need tomcat as it will use embedded tomcat but still you need to have mysql installed, if you want to use mysql.
But on production, you create a war of your app using 'grails war command' and you deploy this war to a web container just like any other war, so you need tomcat and you will need mysql installed too.
In one word answer is 'Yes'.
Fact is when you are in development environment grails uses as an embedded tomcat server provided by the 'Apache Tomcat plugin' which version corresponds to grails version.
You've not installed mysql and you claimed 'it seems working'. That's funny! But it's not mysql who is working without being installed(!), rather it's also an integrated database provided by the 'H2 Database Plugin'.
So, when you'll deploy your grails app in Linux or another server certainly you need a tomcat server to handle user request to that app and a database where your data will be saved.
Related
I am confused by Oracle documentation on how to setup the (ATG) Web Commerce available on the edelivery website.
I would like to get to the step where I have properly set up the admin console.
Running the bin files on a server seems not work for various reasons:
either installation finishes but nothing is working
OR
the installation endlessly asks for arbitrary input.
Also, I want to know if it is possible to setup the server in docker and/or an Amazon Linux EC2 instance.
There are quite a number of steps involved in getting the ATG Admin Server up and running. These start with installing a JDK, Application Server and provisioning a database. Once you have gone through the Installer (which you downloaded from the edelivery site) you need to go through a basic setup process using the CIM tool. The installation process (for ATG 11.3.1) is documented here, while the steps to setup a basic application is documented here.
Working through the steps in the CIM tool, you will end up with a deployable .ear file that you can copy to your application server. Once your application server is started, you will be able to access the Dynamo Admin server.
As of version 11.3.1 ATG is officially supported on Docker. Considering that you compile your own .ear file and it can be deployed to an Application Server (such as Weblogic), Docker support won't necessarily provide you with an ATG Image. It will simply allow you to run your compiled artefact on a Docker container. You are more likely wanting to get hold of a Weblogic Docker Image and deploy your ATG artefact there.
I am new to Ruby on Rails. My questions is:
Is it possible to setup Redmine and install the plugins on my local machine (macOS Sierra), test the Redmine application on localhost, once everything has been done successfully, then only deploy it on a Linux server?
If it is possible, which part of the code should I modify in order to deploy it on Linux server successfully? (Both of my local machine and Linux server are running MySQL database)
Yes it is possible and you don't need to change any part of the Redmine code to do so. Deployment of Rails apps is often done with a tool called Capistrano (http://capistranorb.com/), which executes through ssh on your server, checks out the code and does any additional installation steps necessary. This approach requires you to have your app (Redmine and plugins in your case) in a git repository (or subversion etc). In the simplest case, fork redmine on github and add any plugins as git submodules.
As you're unfamiliar with the platform I'd suggest to start with a simple rails app that you create locally. once you have worked out deployment of that to a remote server, tackle Redmine.
Sounds like a lot of upfront effort but it's worth it since it enables you to work on your local machine, make changes and then deploy the changed code with a single command.
If the Redmine installation on your local host has the same installation path as on the production server, then you can just copy the installation files to the production server. You will also have to copy the database to the production server.
If the installation path is different on your local host and production server, then you will have to install the Redmine and plugin on your production server
I'm trying to deploy a ruby on rails application. It uses mysql for
a database. What I would like to do is distribute it as a windows
executable. It should be in such a way that the user can click on the
application and everything will load and a full screen browser window
will appear. This way the user will know nothing about it being a
browser and need no ruby components installed to run the application.
i am using 3.2.6 , ruby 1.9.3 , gem 1.8.24
Has anyone done anything like this?
Well, you can create a portable distribution - self-extracting archive that will extract your Rails application, pre-configured Ruby package with all necessary gems, and a bat-file, that will add Ruby to PATH variable, run Rails server and open browser window. Making a MySQL portable will definitely be a pain in the ass, I presume.
One of the key disadvantages is almost zero level compatibility - some gems will not work on certain systems, incompatible database drivers etc.
I once tried to do the same thing with Apache+MySQL+PHP, ended up using one shared PC as a server, distributing just browser launcher as a standalone app.
This might be a job for JRuby.
Try installing JRuby on your development machine and seeing whether your app runs in JRuby without any compatibility issues. These days that's reasonably likely.
Running your app in JRuby gives you the ability to package up all of Ruby, Rails, your gems and your application as a single .war file which can then be deployed within a java application server like Tomcat (using tools like warbler)
This still leaves you with the task of installing all the infrastructure (database, java, java application server etc).
I'ld try to prepackage a virtual linux box with all what your application needs and release that instead.
And, yes, I am very interested in the final answer as well :-)
I have a Rails app that is stored in CVS because that is our corporate standard. It needs to be deployed to a single production server that is running Rails using Apache and Phusion Passenger.
About the production server:
RedHat Enterprise Linux 5.1
The app is used internally at our company, not hosted externally.
I have root access and can install necessary software.
I have ssh access to the box, and can also run cvs there if needed.
Current Solution:
I have been using a patched version (a couple of CVS fixes) of capistrano for this, but it's overkill. (I've looked at vlad the deployer, but it does not support CVS.) I want something simpler, with fewer dependencies/patches.
Desired Solution:
I want deployment to be a single command that checks out the tip of the CVS tree and deploys it.
I want rollback to be a single command that reverts to the previously installed version.
A couple of Rakefile tasks, or a shell script would be fine.
Releases need to be uniquely identifiable--either via timestamp, CVS tag, or some sort of version number.
Capistrano is the current gold standard for Rails application deployment; if you already have it working, why do you want to change it?
I want to start experimenting with all these different web frameworks that are available. I was wondering if they could all run in one machine at the same time?
I know that all my database services can all run at the same time, along with the Javascript frameworks, but what about something like Rails and Java applications? Can those play along with each other? Will Apache handle all of this for me?
Yes, since almost any language framework runs as normal code for the language, simply providing structure for applications you write, they can coexist well with other frameworks for the same or other languages. You can certainly run Rails and a Java framework on the same machine - you could even run Rails on JRuby and a Java application server
It sounds like you're just getting started programming. I would recommend learning some of the basics first. For instance, if you want to learn Ruby, try the Pickaxe book, write some simple scripts, then move on to a ruby web framework like Sinatra or Rails. You'll have a better understanding of the difference between a language and framework, how each is installed and run on your machine, etc.
The easiest way to begin experimenting is to use the development server that is included with the various frameworks and run the server on a different port (not 80). For Rails, this is done via:
ruby script\server
which will start a server on port 3000.
Other frameworks use other approaches. Most tutorials for Ruby and Python frameworks (with which I am most familiar) will include instructions on how to start a development server like this.
I don't see why not. It really depends on how the frameworks are deployed and in what containers. If they use separate containers (e.g. tomcat vs apache) you'll need to make sure that the containers are configured to use different ports since many web containers use 80 or 8080.
If you plan on running them all in the same container (e.g. Apache) then I would think they'd be fine, since each one can be treated as a separate web application and deployed to a different location in your document root.
For the most part, it'll probably be trial and error. I don't know much about how Rails interacts with Java, but I've run Grails and Java applications together easily myself with few problems.
I run Rails, PHP, and Java with one Apache server. Except for what felt like a ton of apache config munging when I set it all up, it's been fine. I'm not much of a sysadmin, so it took me a few days to get everything running right.
PHP, Java and Rails all have environments that let you run independent servers and save complex configuration.
Java you can use Tomcat or Jetty.
Rails comes with Webrick, which is fine for development.
PHP has XAMPP (or MAMP if your on the Mac) gives you a complete stack.
I run Rails and ASP.NET MVC on the same Machine and I just set my local servers to run on different ports. But usually the default setup (e.g. Rails on port 3000) will not conflictwith each other, plus each framework usually has its own way to run (LAMP, Webrick, Montgrel...) so you should be fine.