I've seen problems stem from confusing grunt-connect and grunt-contrib-connect(See grunt connect port option ignored and grunt watch & connect)
Given their similarity and conflicting natures, could someone describe their syntactical differences, as well as any functional differences?
grunt-connect
For when you want to run a server indefinitely, for example on a web server (note: this is not what grunt is intended for, instead use grunt to process files, then something like nodejs or apache HTTP server, to host the processed files).
grunt-contrib-connect
When you want to start a web server for other grunt tasks to use.
grunt-serve
This is similar to grunt-connect and is what I use in my projects.
Related
As we all know, we can run a meteor app by just typing meteor in a terminal.
By default it will start a server and use port 3000.
So why do I need to deploy it using MUP etc.
I can configure it to use port 80 or use nginx to route to port 80 for the app. So the port is not the point.
Edit:
Assume meteor is running on a VPS or cloud server with public IP address, not a personal computer.
MUP does a few extra things you can do yourself:
it 'bundles' the code into a single file, using meteor build bundle
the javascript is one file, and css another; it's minified, and obfuscated so it's smaller and faster to load, and less easy to decipher on the client.
some packages are also meant to be removed when running in production. For example meteorToys, the utility toolset to look up collections and much more, is not bundled into the production bundle, as per the instructions in its package. This insures you don't deploy code with security vulnerabilities (Meteor toys basically opens up client side delete / updates etc... if you're not careful)
So, in short, it installs a minimal version of your site, making sure that what's meant for development only doesn't get push to a production environment.
EDIT: On other reason to do this, is that you don't need all the Meteor build tools on your production server; that can add up to a lot of stuff, especially if you keep caches going for a while...
I believe it also takes care of hooking up to a remote MongoDB Instance (at least it used to be the case on the free meteor site) which is more scalable and fault tolerant than running on the same instance as the web server, as well as provision storage etc... if needed.
basically, to deploy a Meteor app yourself manually, you need to:
on your dev box:
meteor build bundle your app to a tar file (using the architecture flag corresponding to the OS you will use)
on the server:
install node v0.10 (or whatever is the current version of node required by Meteor)
you might have to install Fiber#1.0.5 (but I believe this is now part of meteor install already)
untar the bundle, get into bundle/programs/server/ and run npm install
run the server with node main.js in the bundle folder.
The purpose of deploying an application is that you are situating your project on hardware outside of your local machine. For example if you deploy an application on Heroku app you create a repository on heroku's systems and that code based is used to serve your application off of their servers.
If you just start an application on your personal system, you will suffer a lack of network and resource availability as well as under use of computer time at non-peak hours as your system will need to remain attentive for additional users without having alternative tasks. Hosting providers provide resources as needed, and their diverse client base allows their systems to work around the clock on a global scale.
So, I have completed developing a website using Play 2.2 framework. I have a basic question of How to deploy the play application? I have followed the steps given in Play Production mode and generated files in target/universal/stage/bin and all related files using [project]$ dist command. Now, What I have to do with the files that are generated ? How can I put this live? Please specify steps require to deploy this application or a helpful article.
I am a newbie so this question may be too simple to ask.
Thanks :)
That's easy:
send the unziped files to server
find start and make it executable : chmod +x start
start the application on port 80 like ./start -Dhttp.port=80 (don't forget to use nohup, otherwise application will terminate, when you'll close SSH session)
That's all
Tip for easier maintenance you can use for an instance Jenkins - or some other CI system - with rsync command you can prepare one-click task for redeploying app even at distant location.
If you need to run more than 1 application at port 80 on the same machine use some lightweight HTTP server for reverse proxy and/or load balancing, i.e. nginx works perfect.
For production why should I "bundle" the meteor application and not just copy
the sources on the server use the "meteor" command?
Basically what is the difference between:
"meteor bundle app.tar.gz", then installing the right version of fibers and nodejs
and extracting the archive and starting with "node main.js" the app,
and copying the project sources on the server and just writing "meteor" to start
the app?
This won't be an exhaustive list, but here are some things that the meteor command does:
creates a local database
watches on every dependent file in your app or in your packages
sends every file separately and unminified to the client (this is super inefficient unless you are developing locally)
In contrast, bundling an app:
does not create a local database
does not spend CPU watching your files for changes
creates two minified files (js and css) which is perfect for putting on a CDN or hosting from a reverse proxy. These are also efficient for clients to download and are highly cacheable.
In general, deploying shouldn't be a huge pain if you use a good set of scripts.
When using a bundle:
It will not spawn meteor-mongo(Mongodb inside meteor)
No hot reloads
Meteor will not watch your files.
You can leave/quit the server without killing your app.
You can manage node processes smoothly by using pm2 or other similar npm packages.
You can decide where to put your mongoDB and decide what port to use.
You can connect to your mongodb remotely by not having to run your meteor app.
While using a copy or running meteor command in the project directory:
You can't leave/quit the server while keeping the project running without using any screen multiplexers (e.g. tmux)
You can only use meteor's assigned mongodb which is spawned in localhost:3001 -- if meteor is using port 3000.
You are letting meteor to watch over file changes which uses CPU.
When your app dies, your db dies. :)
I am just starting to get my head wrapped around continuous deployment with Jenkins, but I am running into some roadblocks and I haven't really found very many good, definitive resources on the topic in regards to ASP.NET applications.
I have set up a local build server than successfully pulls down code from a SVN repo, and builds it OK with MSBuild. This works well so far, but now I'd like to automate pushing this compiled code to a development server.
My problem is this - from what I gather based on what I read (which may be an incorrect assumption...) is that the staging server is typically within the same network as the build server, meaning you can share network resources, servers, etc.
In my case, I want to run the Jenkins server on a remote VPS, then deploy to other remote VPSes (so, essentially individual isolated machines communicating with each other).
I have seen alot of terms, but I am very new in my Sys Admin / DevOps type skills.
So, my question is this:
Is it even possible to, using Jenkins on a VPS, to then deploy to any particular server I choose? (I have full access to all of them, so if its a security thing, I can fix that... but they are not within the same network/domain)
What is the method to achieve this? I've seen xcopy, Web Deployment Packages (msdeploy), batch scripts, etc. mentioned, but not really a guidance behind what to use in what situations. Are any of these methods useful to achieve my goal?
Thanks for any help or guidance!
How is your Powershell? ;) You should check out psake.
psake is a build automation tool written in PowerShell. It avoids the
angle-bracket tax associated with executable XML by leveraging the
PowerShell syntax in your build scripts. psake has a syntax inspired
by rake (aka make in Ruby) and bake (aka make in Boo), but is easier
to script because it leverages your existent command-line knowledge.
psake is pronounced sake – as in Japanese rice wine. It does NOT rhyme
with make, bake, or rake.
You can deploy your files to the target server through SSH. Jenkins do support transfers through SSH. All you need to do is setting up a SSH server ex : CopSSH and a user account with admin permissions. and configuring the Jenkins to transfer through SSH.
Create host configurations in the main Jenkins configuration
Add an SSH Server
Add the public key to the remote server (the build server)
Click "Test Configuration"
Save
Configure a job to Publish Over SSH (Post Build Action)
Add Transfer Set.
Refer Publish Over SSH For More details
I need to deploy a website from the SVN to different servers all within our own network. The code is currently not compiled but probably will be in the future.
First, the site would need to be deployed to the development server for the developers to test.
Once the Developer signs off, it would be deployed to the staging server for the testers.
Once final sign off was given it would be deployed to a server farm- two live servers.
Each server has a couple of settings in the web.config to that are different (except the two live servers, of course). I would like to use templates, the way the Ruby on Rails world does. It seems like an elegant solution to multiple web.config files.
I also need to create a list/report of the files that were changed and what the change was since the last deployment.
I am thinking of writing a script that will do the following:
1. Take args for server to deploy to, and revision
2. Export a copy of the source to a directory with svn export -r <deploy revision>
3. Delete the web.config file
4. Use ttree (a template tool http://template-toolkit.org/) to create the correct web.config
5. Create a list of file changes with svn list -r <deploy revision>:<current server revision>
6. Store the <current server revision> of the website for when the script is run next time
The problem I have is it doesn't seem like the most elegant solution. It could become unmaintainable, and I prefer to use tools that are already available rather than re-invent the wheel. Unfortunately I don't think MSDeploy will do what I need, but I'm happy to use it, or anything else, if it will do what I need it to. Does anyone know of any tools that are up to the task or is the script my only option?
Check out TeamCity. I have my build server setup so that it can deploy to different environments with different settings based on the build configuration all in "One Click". It's relatively painless to setup and integrates directly with Subversion and other source control systems. This would be a more elegant solution to the issue you are dealing with...