I'm enthusiastic and passionate about web development and design in all it's forms and love to build application with efficient and simple methods

Monday, October 5, 2015

How To Install Linux, Apache, MySQL, PHP (LAMP) stack on Ubuntu

8:40 PM Posted by Codeinterpreter No comments
About LAMP

LAMP stack is a group of open source software used to get web servers up and running. The acronym stands for Linux, Apache, MySQL, and PHP. Since the virtual private server is already running Ubuntu, the linux part is taken care of. Here is how to install the rest.

Wednesday, July 8, 2015

Vagrant Rails Puppet. Organizing Manifests with Modules

6:41 PM Posted by Codeinterpreter No comments
Built Puppet Manifests using modules allow us to organize our manifests into logical pieces, much as we do with modules in Ruby or packages in Java. We’ve already gotten started on a module structure for our Apache-related Puppet configuration by creating a modules/apache2/files directory holding our customized apache2.conf


Configurations

in your puppet folder create this filer manifests/site.pp

apply your puppet and check it's working: sudo puppet apply --verbose manifests/site.pp

 Exec {
  path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
 }
 include apache2


create your virtual host in here: modules/apache2/files/massiveapp.conf


  ServerName myapp
  DocumentRoot "/var/myapp/current/public/"
  CustomLog /var/log/apache2/myapp-access_log combined
  ErrorLog /var/log/apache2/myapp-error_log

In your puppet folder built this directory files: modules/apache2/manifests/init.pp
in init.pp create this config:

package {
  "apache2":
  ensure => present,
  before => File["/etc/apache2/apache2.conf"]
}

service {
  "apache2":
  ensure => true,
  enable => true,
  subscribe => File["/etc/apache2/apache2.conf"]
}

file {
"/etc/apache2/apache2.conf":
  owner => root,
  group => root,
  mode => 644,
  source => "puppet:///modules/apache2/apache2.conf";

"/etc/apache2/sites-enabled/massiveapp.conf":
  source => "puppet:///modules/apache2/massiveapp.conf",
  owner => root,
  group => root,
  notify => Service["apache2"],
  require => Package["apache2"];
}

file {
"/etc/apache2/apache2.conf":
  owner => root,
  group => root,
  mode => 644,
  source => "puppet:///modules/apache2/apache2.conf";
"/etc/apache2/sites-enabled/massiveapp.conf":
  source => "puppet:///modules/apache2/massiveapp.conf",
  owner => root,
  group => root,
  notify => Service["apache2"],
  require => Package["apache2"];
}








Wednesday, July 1, 2015

Deploy Code with Capistrano

7:34 AM Posted by Codeinterpreter No comments
Developing a web application isn’t going to do much good if we aren’t able to find a way for the world to see it. For other web frameworks,this can often be a tedious and time-consuming process. Application code needs to be updated, database schemas need to be migrated, and application servers must be restarted. We could do all of this manually by ssh into the server, pulling the latest code from the repository, running database migration tasks, and restarting the application server. Even better, we could write some shell scripts that would automatically perform these tasks for us. But why do all that when we could be spending time improving App instead?

The good news is that we don’t have to do all that.Battle-tested and used for deploying many of today’s Rails apps, Capistrano (originally authored by Jamis Buck and now ably maintained by Lee Hambley) is the tool that Rails developers have used for years to get their applications from development to production on a daily basis. It was built from the start for deploying Rails applications, and it has all the tools we need to get App deployed and to help keep deployments running smoothly afterward. Capistrano’s library of tasks, plugins, and utilities has also evolved over the years with the rest of the Rails ecosystem, and thus Capistrano continues to meet the deployment needs of Rails applications both new and old.

Configuration

Add capistrano gem to development environment

group :development do
gem 'capistrano', '~> 2.11.2'
end

Don't forget to bundle update. and check your capistrano instalation by: cap -H

Generate necessarily file with :

capify .

// Will generate:
[add] writing './Capfile' // created in project’s root directory and takes care of loading Capistrano’s default tasks
[add] writing './config/deploy.rb' // Rails asset pipeline tasks, and our primary deployment script
[done] capified!

Settings

Example of config settings in /config/deploy.rb
require 'bundler/capistrano'

// Configurations from repository
set :application, "massiveapp"
set :scm, :git
set :repository, "git://github.com/myapp/myapp.git"

// Tell capistrano about server address host
server "localhost", :web, :app, :db, :primary => true
// port running in server
ssh_options[:port] = 2222
// path to private key
ssh_options[:keys] = "~/.vagrant.d/insecure_private_key"

set :user, "vagrant"
set :stages, %w(staging production)
set :default_stage, 'staging'
set :use_sudo, false
set :group, "vagrant"
set :deploy_to, "/var/myapp"
set :deploy_via, :copy
set :copy_strategy, :export

namespace :deploy do
  task :start do ; end
  task :stop do ; end
  desc "Restart the application"
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
  end
  desc "Copy the database.yml file into the latest release"
  task :copy_in_database_yml do
    run "cp #{shared_path}/config/database.yml #{latest_release}/config/"
  end
end
// task that copy database.yml file into place, so we’ll put that here as well as a before directive that will force that task to be called as part of a deployment
before "deploy:assets:precompile", "deploy:copy_in_database_yml"

Setting in Server

From console application
cap deploy:setup

- /releases
- /shared
|- /log
|- /system
|- /pids


Each time we deploy, Capistrano will create a new subdirectory in the releases directory and place the source code for Application there. The shared directory will contain various, well, shared resources. Thus, shared/log will contain Application log files, and shared/system will contain any files that need to be kept from deployment to deployment. We also have shared/config, which we created with Puppet and which contains Application database.yml.

Push Command from Local


// as describe in /config/deploy.rb set_staging.
cap deploy staging



Vagrant Rails Puppet

1:02 AM Posted by Codeinterpreter No comments
Vagrant & Puppet to easily provision virtual machines that can be used as isolated development environments for your projects. You'll keep your development machine fast, your environments isolated, and any developer will be able to get up and running on a new project in less than 5 minutes.

Puppet automates server provisioning by formalizing a server’s configuration into manifests. Puppet’s manifests are text files that contain declarations written in Puppet’s domain-specific language (DSL). When we’ve defined our configuration using this DSL, Puppet will ensure that the machine’s files, packages, and services match the settings we’ve specified


Configuration


// Initialize vagrant
vagrant up

// Enter Vagrant SSH
vagrant ssh
// Built Git repository for manifest. built it if not exist
ls -l /etc/puppet/.git/
// First we need to create a user and group for Puppet to use
sudo useradd --comment "Puppet" --no-create-home \ --system --shell /bin/false puppet

// Installing puppet as ruby gem. This will install puppet and facter
sudo gem install puppet -v 2.7.12 --no-rdoc --no-ri

facter is the tool that Puppet uses to gather information about the system in order to populate variables and determine which parts of our.

// Run Facter
facter

// Built manifests and site.pp in /etc/puppet
cd /etc/puppet
mkdir manifests
cd manifests
sudo nano site.pp

write this configuration:
Exec {
  path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
}

// Commit this change
git add .
git commit -m "Init Puppet manifests"

Puppet Configurations


puppet help apply

// Run puppet
sudo puppet apply --verbose manifests/site.pp


When developing a Puppet configuration, it’s helpful to pass the --verbose flag to Puppet so that it displays any extended information that might be available if an error happens. We’ll see output like this from puppet apply:

 info: Applying configuration version '1319427535' info: Creating state file /var/lib/puppet/state/state.yaml notice: Finished catalog run in 0.02 seconds We’ll also see a few lines of output like the following ones.

This is because the Puppet developers are still bringing the codebase up-to-date for Ruby 1.9.3; these should go away in future Puppet releases.

 Could not load confine test 'operatingsystem': cannot load such file \ --  puppet/provider/confine/operatingsystem

 We’ve successfully built a tiny Puppet repository and executed Puppet on our VM. Now we’ll build out the VM with a standard Rails application stack. That is, we’ll configure Apache, MySQL, and Passenger, and we’ll put the Rails application directory tree into place. Along the way, we’ll learn all about how Puppet helps us manage our VM’s services and configuration.

Study Case

Installing Apache  on a server

In our site.pp. add this conf:
Exec {
path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
}
package {
"apache2":
ensure => present
}
service {
"apache2":
ensure => true,
enable => true
}


This package declaration is a fine example of the Puppet DSL. There’s a type declaration, package, followed by a block delimited by curly braces. That block contains a title for the instance of the type that we’re configuring, apache2.
That title is associated with various parameters that affect how Puppet will act on the type. In this case, we’ve declared an ensure parameter that’s set to present. This declaration is our way to tell Puppet that it should ensure there is a package called apache2 installed on the system.

service apache ensure true it means setting Puppet to attempt the service if it’s not running. And enable means ensures the service will start on boot


// Apply puppet
sudo puppet apply --verbose manifests/site.pp

If there's error message: "Could not load confine test 'operatingsystem' ". That's just update issue and harmless. If affecting your process just update your RoR versions.




Tuesday, June 30, 2015

Vagrant: Built Customize Vagrant Box

7:25 PM Posted by Codeinterpreter No comments

Built Customize Vagrant Box

We can make customize box from our vagrant existed box. With this, we can change our environment in existing box and customize it according our need.




Scripting

// In your Vagrant Init file directory
vagrant up
// Get in to your vagrant environment
vagrant ssh

/*
 * Do your custumize in here
 * For example. I will remove my existing ruby version from vagrant box and change it to new one
 */

sudo apt-get update -y

sudo apt-get install build-essential zlib1g-dev libssl-dev libreadline-dev \
git-core curl libyaml-dev libcurl4-dev libsqlite3-dev apache2-dev -y

curl --remote-name http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p194.tar.gz

tar zxf ruby-1.9.3-p194.tar.gz

cd ruby-1.9.3-p194/

./configure

make

sudo make install

// Check if my new ruby version successfully installed
ruby -v

// If succeed quit from vagrant ssh
exit

// Adding your customize box to new box
vagrant package

// Name it
vagrant box add lucid64_with_ruby193 package.box

// Check for your new box
vagrant box list

- lucid32
- lucid64
- lucid64_with_ruby193

// Activate your vagrant 
vagrant init lucid64_with_ruby193