I have a web service in ruby, and i want to run my ruby service via chef recipe.
I have used execute command as :
execute 'start-ruby' do
command 'ruby /opt/certificate.rb start'
action :run
end
I can see my ruby service running in background on my Amazon instance, but somehow Instance setup is stuck in running setup.
Is there any other alternative from which i can run my ruby service via chef recipe.
The execute resource runs its command synchronously, meaning it waits for it to finish before continuing with the recipe. I'm guessing your start command there starts a foreground-mode daemon (which is how it should work) so it never returns and Chef just waits forever.
Check out https://github.com/poise/application_examples/blob/master/recipes/todo_rails.rb or https://github.com/poise/poise-service for examples of Ruby application deployment and generic service management respectively.
Related
So, struggling with a fairly major problem, i've tried multiple different workarounds to try and get this working but there is something happening between puppet and the actual server that is just boggling my mind.
Basically, I have an init.d script /etc/init.d/rserve which is copied over correctly and when used from the command-line on the server works perfectly (i.e. sudo service rserve start|stop|status), the service returns correct error codes based on testing using echo $? on the different commands.
The puppet service statement is as follows:
service { 'rserve':
ensure => running,
enable => true,
require => [File["/etc/init.d/rserve"], Package['r-base'], Exec['install-r-packages']]
}
When puppet hits this service, it runs it's status method, sees that it isn't running and sets it to running and presumably starts the service, the output from puppet is below:
==> twine: debug: /Schedule[weekly]: Skipping device resources because running on a host
==> twine: debug: /Schedule[puppet]: Skipping device resources because running on a host
==> twine: debug: Service[rserve](provider=upstart): Could not find rserve.conf in /etc/init
==> twine: debug: Service[rserve](provider=upstart): Could not find rserve.conf in /etc/init.d
==> twine: debug: Service[rserve](provider=upstart): Could not find rserve in /etc/init
==> twine: debug: Service[rserve](provider=upstart): Executing '/etc/init.d/rserve status'
==> twine: debug: Service[rserve](provider=upstart): Executing '/etc/init.d/rserve start'
==> twine: notice: /Stage[main]/Etl/Service[rserve]/ensure: ensure changed 'stopped' to 'running'
Now when I actually check for the service using sudo service rserve status or ps aux | grep Rserve the service is in fact NOT running and a quick sudo service rserve start shows the init.d script is working fine and starting rserve as the service starts and is visible with ps aux.
Is there something I'm missing here? I've even tried starting the service by creating a puppet Exec { "sudo service rserve start"} which still reports that it executed successfully but the service is still not running on the server.
tl;dr puppet says a service started when it hasn't and there's seemingly nothing wrong with the init.d script, its exit codes or otherwise.
Update 1
In the comments below you can see I tried isolating the service in it's own test.pp file and running it using puppet apply on the server with the same result.
Update 2
I've now tried creating an .sh file with the command to start Rserve using a separate vagrant provision and can finally see an error. However, the error is confusing as the error does not occur when simply running sudo service rserve start, something in the way that vagrant executes .sh commands, or the user it executes them under is causing an option to be removed from the command inside the init.d script when it's executed.
This error is R and Rserve specific but it is complaining about a missing flag --no-save needing to be passed to R when it is in fact present in the init.d script and being correctly passed when ssh'd into the vagrant box and using the init.d commands.
Update 3
I've managed to get the whole process working at this point, however, it's one of those situations where the steps to get it to work didn't really readily reveal any understanding of why the original problem existed. I'm going to replicate the broken version and see if I can figure out what exactly was going on using one of the methods mentioned in the comments so that I can potentially post an answer up that will help someone out later on. If anyone has insight into why this might have been happening feel free to answer in the meantime however. To clarify the situation a bit, here are some details:
The service's dependencies were installed correctly using puppet
The service used a script in /etc/init.d on ubuntu to start|stop the Rserve service
The software in question is R (r-base) and Rserve (a communication layer between other langs and R)
Running the command sudo service rserve start from the command-line worked as expected
The init.d script returned correct error codes
A service {} block was being used to start the service from puppet
Puppet reported starting the service when the service wasn't started
Adding a provision option to the Vagrantfile for an .sh file containing sudo service rserve start revealed that some arguments in the init.d were being ignored when run by vagrants provisioning but not by a user active on the shell.
I have a service resource but I can't get chef to start it, instead chef just spits out an error message:
SystemCallError: The specified service does not exist as an installed service. - OpenService: The specified service does not exist as an installed service.
I'm not sure what to do to fix this and I can't find anything on this error (could be I'm not looking in the right place).
The service is distributed as a gem that's installed.
The service itself is a Sinatra app that uses the win32-service gem to start it as a service
The platform is windows server (I know but I have no choice, I have to use windows server)
The code in the chef recipe for this service is:
service service_name do
init_command ("#{%x(gem env gemdir).strip.gsub('/','\\')}\\gems\\#{service_name}-#{installing_version}")
start_command "rake service:start"
stop_command "rake service:stop"
reload_command "rake service:reload"
restart_command "rake service:restart"
supports start: true, restart: true, reload: true
action [:enable,:start]
end
The issue is not with Chef, but with your service itself. Typically when I'm in this situation, I will login manually and attempt to start the service. Sometimes that will give you additional information. Also, take a look at the log files for your app and see if you can figure out why it's not starting.
Ultimately, Chef just calls your init and start commands, but it can't do much if those commands fail.
What is an example of a way to run a test against a server? In other words, how would you run a server and then run a test client against the server from a make file? For example, I want to run make test which will run all tests against the server to verify it's passing all tests. I know how to run a test for a single program, say against a library, but not how to run two programs that are dependent for the test, at once.
It is more convenient to have a shell script that spawns multiple processes and orchestrates them because each line of a makefile recipe is a new invocation of the shell. Use make to invoke that test shell script that would do something like:
Start the server in the background.
Start the client.
Run tests.
Terminate the client.
Terminate the server.
Return the process return code indicating test success or failure.
We have a project with different processes, and run it by calling erl -pa ebin, mymodule_supervisor:start_link().
We have set up an ubuntu instance on Amazon EC2. Being new to this, how can we run the project remotely, so we can close the connection and the project will continue to run?
We can run the Erlang shell in the background, but we can't our project on it. It would be perfect to see an example.
Method 1: You could build a release package from your code. If done right, this will embed a complete Erlang system (along with your application and its dependencies) in an easily distributable tar file. Using an automatically generated script the node can then be started as a daemon, running in the background even after you close your shell.
A good way to get started is to use Rebar, which already supports release handling out of the box.
Method 2: Use tmux or screen (both easily installed on Ubuntu) to start your node and detach the session. If you choose tmux, the following should work:
Start tmux simply by running tmux from a shell.
From within tmux, start your node with the erl command as before.
Detach your session using Ctrl-b followed by d. Exit your shell. The node should still be running.
The "proper" way to start the supervisor is to call its start_link function from within the start function of your Erlang application.
need pretty trivial task
i have server, which in crontab every night will run "something" what will launch new EC2 instance, deploy there code (ruby script), run it, upon completion of the script shutdown the instance.
how to do it the best?
thanks.
Here's an approach that can accomplish this without any external computer/cron job:
EC2 AutoScaling supports schedules for running instances. You could use this to start an instance at a particular time each night.
The instance could be of an AMI that has a startup script that does the setup and running of the job. Or, you could specify a user-data script be passed to the instance that does this job for you.
The script could terminate the instance when it has completed running.
If you are running EBS boot instance, then shutdown -h now in your script will terminate the instance if you specify instance-initiated-shutdown-behavior of terminate.