CloudFoundry nodeJS tutorial is out of date? - cloud-foundry

I'm following the nodeJS tutorial and as I get the point of pushing the application to Cloudfoundry.com the push flow in the tutorial and the one I see are very different.
I use vmc 0.999 and this is what I see:
Name> hello-node
Instances> 1
1: node 2: other Framework> node
1: node 2: node06 3: node08 4: other Runtime> 3
1: 64M 2: 128M 3: 256M 4: 512M 5: 1G 6: 2G Memory Limit> 64M
Creating ido-hello-node... OK
1: ido-hello-node.cloudfoundry.com 2: none URL>
ido-hello-node.cloudfoundry.com
Updating ido-hello-node... OK
Create services for application?> n
Save configuration?> y
Saving to manifest.yml... OK Uploading ido-hello-node... OK Using
manifest file manifest.yml
Starting ido-hello-node... OK Checking ido-hello-node
Am I doing something wrong or is the tutorial simply out-dated?

There is no vmc 0.999 so I am not sure what version you actually have - the latest version as of now (obtained by typing 'gem install vmc --pre') is vmc-0.5.0-rc1. You can check which version you have using 'vmc --version'
Yes, the tutorials at http://docs.cloudfoundry.com are outdated and we are busy working on updated versions at http://cloudfoundry.github.com.
You can find the latest Node tutorial here: http://cloudfoundry.github.com/docs/using/deploying-apps/javascript/
If you find any mistakes or would like to suggest additions please feel free to contribute by sending a Github pull request.

It looks like your application pushed successfully. Was there a problem running it?
The vmc command is changing, and the docs you reference may be getting out of date. New docs are being created and published here: http://cloudfoundry.github.com/docs/using/deploying-apps/javascript/. These docs are a work-in-progress, but are more up to date.

Related

Problem with running locally with dockers

I'm following a google video to start a google cloud project with vscode and it throws me an error and I can't solve it
this is the video just in case https://youtu.be/EtMIEtLQNa0?t=298
Starting to run the app using configuration 'Cloud Run: Run/Debug Locally' from .vscode/launch.json...
To view more detailed logs, go to Output channel : "Cloud Run: Run/Debug Locally - Detailed"
Dependency check started
Dependency check succeeded
Unpausing minikube
The minikube profile 'cloud-run-dev-internal' has been scheduled to stop automatically after exiting Cloud Code. To disable this on future deployments, set autoStop to false in your launch configuration c:\Users\Franco\Desktop\proyecto\Proyecto Agenda Web\.vscode\launch.json
Configuring minikube gcp-auth addon
Using GCP project 'proyecto-agenda-web' with minikube gcp-auth
invalid skaffold config: source: C:\Users\Franco\AppData\Local\Temp\cloud-code-cloud-run-iixzxH\skaffold.yaml, in module "proyecto-agenda-web" on line 7 column 14: source: C:\Users\Franco\AppData\Local\Temp\cloud-code-cloud-run-iixzxH\skaffold.yaml, in module "proyecto-agenda-web" on line 7 column 14: invalid image "Proyecto Agenda Web": invalid reference format
source: C:\Users\Franco\AppData\Local\Temp\cloud-code-cloud-run-iixzxH\skaffold.yaml, in module "proyecto-agenda-web" on line 7 column 14: source: C:\Users\Franco\AppData\Local\Temp\cloud-code-cloud-run-iixzxH\skaffold.yaml, in module "proyecto-agenda-web" on line 7 column 14: invalid image "Proyecto Agenda Web": invalid reference format
Skaffold exited with code 1.
Cleaning up...
Finished clean up.```
I've been searching and I can't think of a solution, any ideas?
The error is descriptive:
invalid skaffold config:
source: C:\Users\Franco\AppData\Local\Temp\cloud-code-cloud-run-iixzxH\skaffold.yaml
on line 7
column 14
invalid image "Proyecto Agenda Web"
invalid reference format
You have a folder called skaffold.yaml in that directory.
On line 7, column 14, there's probably something of the form image: Proyecto Agenda Web and Projecto Agenda Web isn't a valid container image.
These are generally of the form some-repo/some-image:some-tag.
You need to correct that. There may be subsequent errors.
I assume (!?) somewhere in the video, there are instructions that explain what value to use there.

Django Celery with Redis Issues on Digital Ocean App Platform

After quite a bit of trial and error and a step by step attempt to find solutions I thought I share the problems here and answer them myself according to what I've found. There is not too much documentation on this anywhere except small bits and pieces and this will hopefully help others in the future.
Please note that this is specific to Django, Celery, Redis and the Digital Ocean App Platform.
This is mostly about the below errors and further resulting implications:
OSError: [Errno 38] Function not implemented
and
Cannot connect to redis://......
The first error happens when you try run the celery command celery -A your_app worker --beat -l info
or similar on the App Platform. It appears that this is currently not supported on digital ocean. The second error occurs when you make a number of potential mistakes.
PART 1:
While Digital Ocean might remedy this in the future here is an approach that will offer a workaround. The problem is the not supported execution pool. Google "celery execution pools" if you want to know more and how they work. The default one is prefork. But what you need is either gevent or eventlet. I went with the former for my purposes.
Whichever you pick you will have to install it as it doesn't come with celery by default. In my case it was: pip install gevent (and don't forget adding it to your requirements as well).
Once you have that you can re-run the celery command but note that gevent and beat are not supported within a single command (will result in an error). Instead do the following:
celery -A your_app worker --pool=gevent -l info
and then separately (if you want to run beat that is) in another terminal/console
celery -A your_app beat -l info
In the first line you can also specify the concurrency like so: --concurrency=100. This is not required but useful. Read up on it what it does as that goes beyond the solution here.
PART 2:
In my specific case I've tested the above locally (development) first to make sure they work. The next issue was getting this into production. I use Redis as the db/broker.
In my specific setup I have most of my celery configuration in the_main_app/celery/__init__.py file but sometimes people put it directly into the_main_app/celery.py. Whichever it is you do make sure that the REDIS_URL is set correctly. For development it usually looks something like this:
YOUR_VAR_NAME = os.environ.get('REDIS_URL', 'redis://localhost:6379') where YOUR_VAR_NAME is then set to the broker with everything as below:
YOUR_VAR_NAME = os.environ.get('REDIS_URL', 'redis://localhost:6379')
app = Celery('the_main_app')
app.conf.broker_url = YOUR_VAR_NAME
The remaining settings are all documented on the "celery first steps with django" help page but are not relevant for what I am showing here.
PART 3:
When you setup your Redis Database on the App Platform (which is very simple) you will see the connection details as 'public network' and 'VPC network'.
The celery documentation says to use the following URL format for production: redis://:password#hostname:port/db_number. This didn't work. If you are not using a yaml file then you can simply copy paste the entire connection string (select from the dropdown!) from the Redis DB connection details and then setup an App-Level environment variable in your Digital Ocean project named REDIS_URL and paste in that entire string (and also encrypt it!).
The string should look like something like this (redis with 2 s!)
rediss://USER:PASS#URL.db.ondigitialocean.com:PORT.
You are almost done. The last step is to setup the workers. It was fine for me to run the PART 1 commands as console commands on the App Platform to test them but eventually I've setup a small worker (+ Add Component) for each line pasted them into the Run Command.
That is basically the process step by step. Good luck!

500 Internal Server Error - ActionView::Template::Error in Rails Production second pass

Loved the previous question at:
500 Internal Server Error - ActionView::Template::Error in Rails Production
I get the same error when browsing the git tree via the web (internal 500), but the answer there said I should run
bundle exec rake assets:precompile
and referred me to
http://guides.rubyonrails.org/asset_pipeline.html#in-production
I am running GitLab 7.6.1 0286222 on Ubuntu 14.04 LTS fully up to date. That allows me to push and pull from local git machines fine and look around via the web service as well. I ran the revised assets:precompile as suggested below, but the problem continues for me.
So as to my specific error. In the production log I get:
git#git01:~/gitlab/log$ tail -n 20 production.log
Started GET "/chef/cheftest/tree/master/cookbooks" for 127.0.0.1 at 2014-12-24 16:03:25 -0500
Processing by Projects::TreeController#show as HTML
Parameters: {"project_id"=>"chef/cheftest", "id"=>"master/cookbooks"}
Completed 500 Internal Server Error in 490ms
ActionView::Template::Error (undefined method `[]' for nil:NilClass):
1: - tree, commit = submodule_links(submodule_item)
2: %tr{ class: "tree-item" }
3: %td.tree-item-file-name
4: %i.fa.fa-archive
app/models/repository.rb:162:in `method_missing'
app/models/repository.rb:228:in `submodule_url_for'
app/helpers/submodule_helper.rb:6:in `submodule_links'
app/views/projects/tree/_submodule_item.html.haml:1:in `_app_views_projects_tree__submodule_item_html_haml___742655240099390426_69818877669240'
app/helpers/tree_helper.rb:19:in `render_tree'
app/views/projects/tree/_tree.html.haml:42:in `_app_views_projects_tree__tree_html_haml__47884322835133800_69818822684460'
app/views/projects/tree/show.html.haml:9:in `_app_views_projects_tree_show_html_haml__1575471590709486656_69818822138660'
app/controllers/projects/tree_controller.rb:13:in `show'
I would be happy to run any commands and edit any configuration files as needed, but please let me know where the files are and how to run the commands. Thanks for your help with this.

How to change the storage path from rrdtool on the Ganglia?

How to change the storage path from rrdtool on the Ganglia?
For example: I have a default configuration in my file gmetad.conf, but I want to change to other storage. how to alter this path?
Where gmetad stores its round-robin databases
default: "/var/lib/ganglia/rrds"
rrd_rootdir "/some/other/place"
I tried to change the rrd_rootdir, but doesn't work.
Thanks
Namir Rachid
Well, you forgot few things. But I will elaborate with more details, but before that, you may need to stop gmetad daemon first:
Step 1: Create directory where you want to store rrdtool based data of ganglia
[root#ganglia-server ganglia-3.6.0]# mkdir -p /some/other/place/
Step 2: Make ganglia as the owner of this directory.
[root#ganglia-server ganglia-3.6.0]# chown -R ganglia /some/other/place/
Step 3: Provide appropriate permission also. You may test it otherwise.
[root#ganglia-server ganglia-3.6.0]# chmod -R 777 /some/other/place/
Step 4: Enable /some/other/place in gmetad.conf. Don't forget to remove pound symbol.
# Where gmetad stores its round-robin databases
# default: "/var/lib/ganglia/rrds"
rrd_rootdir "/some/other/place"
# rrd_rootdir "/some/other/place"
Step 5: Test if data is being written in /some/other/place in your gmetad log.
[root#ganglia-server ganglia-3.6.0]# gmetad/gmetad -d 5 -c /etc/ganglia/gmetad.conf
Going to run as user ganglia
Sources are ...
Source: [my cluster, step 15] has 1 sources
127.0.0.1
xml listening on port 8651
interactive xml listening on port 8652
.......
.......
Updating host ganglia-server, metric cpu_steal
Created rrd /some/other/place/default/ganglia-server/cpu_steal.rrd
Updated rrd /some/other/place/default/ganglia-server/cpu_steal.rrd with value 1414567960:0.0
Updating host ganglia-server, metric load_one
Created rrd /some/other/place/default/ganglia-server/load_one.rrd
Updated rrd /some/other/place/default/ganglia-server/load_one.rrd with value 1414567960:0.01
Note: The gmetad executable may be at different location on your machine. Change the location as required to generate the log. In most of the cases, gmetad daemon is installed in "/usr/local/sbin/gmetad".
Step 6: Start the gmetad daemon now.
It worked for me. And, hopefully, it should work for you too.

vmc instances appname 3 gives error: Unknown app '3'

I have installed Ruby and Gems and also installed VMC following the documentation on the cloudfoundry website. I could deploy a simple hello world application successfully. Several commands seem to work fine. However, few commands just fail and I have no clue why.
When I run the following command:
vmc instances hellor 3
I get an error: Unknwon app '3'
When I just run:
vmc instances hellor
It retrieves the instance fine and displays it without any error. But, when I specify a number after that to increase the instances, it just seem to treat that number as an appname and gives me error. What could be the reason. I could not find anyone else facingup this issue on any of the forums. Any help on this will be highly appreciated. I am deploying on cloudfoundry.com
The behavior of this command depends on the version of vmc you are using. You can see the version of vmc you are running with vmc --version.
With vmc version 0.3.x, the instances command works as you are expecting it to in your question. If you run vmc help with version 0.3.x, you will see this among other output:
instances <appname> <num|delta> Scale the application instances up or down
With vmc version 0.4.x (also known as vmc-ng), the instances command works differently and the scale command is introduced, as Hitesh says. If you run vmc help --all with version 0.4.x, you will see this among other ouput:
instances APPS... List an app's instances
scale [APP] Update the instances/memory limit for an application
"vmc instances [APP]" is used to list the number of instances you have. To actually scale your application you can do "vmc scale [APP]" as shown below:
hghia#SEA-007~/workgalaxy/hello$ vmc scale hello
Instances> 3
1: 64M
2: 128M
3: 256M
4: 512M
5: 1G
6: 2G
Memory Limit> 64M
Scaling hello... OK
hghia#SEA-007~/workgalaxy/hello$ vmc instances hello
Getting instances for hello... OK
instance #0: running
started: 2012-12-10 03:41:39 PM
instance #1: running
started: 2012-12-10 03:46:56 PM
instance #2: running
started: 2012-12-10 03:46:56 PM
Thanks,
- Hitesh