I read from this guide http://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html that this deployment is supported through CLI.
Can I use my Pivotal Web Services web interface to do that ?
Does the Green instance connect to the production DB ?
Any guide is greatly appreached
Yes,you can use the web interface to map and unmap routes. When you go to the detail app of your app, you can see at the bottom a tab panel. One of the tabs says 'Routes'. There you can map and unmap routes.
Yes, both instances should be connected to the same db. During a time, when both instances are live (the production route is mapped to both of them), you will have users using the old and the new version. If a user is using the old version, you want his/her edits to be stored and present when he/she is switched over to the new version. Note: That means you should make sure that all your database migrations are backwards compatible.
Related
I'm building a desktop client app (win/linux/mac) with a backend hosted in GCP (I'm considering other cloud platforms too). The desktop app should be minimalistic and provide access to local machine resources to the backend. And I'm looking for a way to invoke my app from the server (when some event occurs) and then the app would do some work on a local machine. Here's what I've tried so far.
Google Cloud Pub/Sub. Seems like it does what I need, but to make it work I have to create a service account, generate JSON key and store it locally, which is not good. I can restrict the service account access permissions, of course, but still it doesn't look good to me. Maybe there are other ways to auth my app running at the end user machine? I want to keep my desktop app minimal (ideally without UI, just an "agent" console process / Windows service). Maybe I could consider a login screen to connect the app with the backend, if that solves the problem, but I don't want to overcomplicate.
Google Cloud Run + SignalR / WebSockets. This solution also looks good, but it has one significant disadvantage. As long as there's at least one open WebSocket the Cloud Run instance is considered active and therefore billed. There are other difficulties related to scalability and container instances synchronization too.
What do you think about the options above, and what are the other possibilities? Am I left with REST API and polling for updates? I'm quite new to the cloud stuff so any help is appreciated. Thanks!
If you want to be able to invoke your local app from Google Cloud, you need 2 things
The first one, to register your app on Google Cloud, with, preferably, a auth mecanism (can be an API key for example). Like this, the GCP backend know where to call you app (which IP/port) and how (the auth mechanism)
The second is to have your app up and running and listen external communication. HTTP is the easiest way. Wait a HTTP call on the IP/port defined during the registration, check the auth and perform the process.
You can store the data (location and the auth) in firestore for example, and use Cloud Run to perform the HTTP call.
You can also inverse the solution and to poll (long polling or regular poll) the backend from the local app when it is running.
The 2 approach are possible, the second one slightly easier but can be challenging to manage the security.
I am very new to GCP and G-Suite. I wanted to understand one basic thing:
If I create an application (to be used within a domain) using App Maker, do I also need access to GCP?
I have done lots of googling [https://support.google.com/a/answer/9142070?hl=en] but couldn't find answer to this.While watching to one video on AppMaker I realised that- I can create application which could interact with G-Suite apps but we can not preview/publish this application without having account/access to GCP as "previewing" an app actually deploys the app on App Engine which is part of GCP. Also "publish" would definitely be doing the same.
Can any one help me in understanding this? I want to start my page development in App Maker and want to spend money on GCP later, this is doable only when preview is not dependent on GCP?
Any quick reference would be appreciated.
Regards.
App Maker is dependant on GCP products: Google Cloud SQL and Google App Engine; Although, the latter one is not being charged. This information is located in the official documentation.
App Maker apps usually store data in Cloud SQL, a Google Cloud Platform (GCP) service that delivers fully managed SQL databases in the cloud.
I had deployed the test application on Production on Google Cloud via App Engine and i could not see the instance is being created as its serverless it could or it could not create the instance.
But I am concerned about the billing since the URL was still running like on :
Example: http://mytestproject-123456.appspot.com/
So I disabled the billing for the project and also the application from the App Engine settings.
Could someone please help or suggest.
Is any action still required to stop the billing if there is any since I had deployed the application on Production and the url was accessible.
1.And If delete the whole project will it work?
If yes please tell the process.
If you want to stop the app from serving requests and running instances, you can disable the application. This way you will not be getting billed for that. Basically, there is no need to delete a billing account or the project to just stop serving requests. Please be aware that you still might be charged for storage, or other GCP services that you are using if applicable.
I would say that you do not need to do anything else. For future reference, before deploying a service, a good practice is to test it locally before deploying and starting to serve requests from users.
I suppose you are talking about the Standard Environment; if i am right, you can see the number of instances by going in the console, choosing your project in the selection control on top of the page. After this, in the left column, select App Engine, and, in the page that shows up, you can see the instances tab. There you will find all the running instances, if any.
If you are using other resources, they will be billed accordingly. If you are not, disabling the application is all you need to protect yourself against unwanted billing.
Hope this helps.
I have been exploring Pivotal Cloud Foundry - Public Cloud Version by setting up an Pivotal Web Services account.
While exploring the CF CLI I followed the below tutorial.
https://pivotal.io/platform/pcf-tutorials/getting-started-with-pivotal-cloud-foundry/introduction
I was able to successfully push the sample spring boot app to PCF Cloud and follow the tutorial.
When I started to play around with it, I tried deleting the app using the below command. cf-spring is my app name.
cf delete cf-spring
When navigated to my Pivotal Web Service account, I could see the app has been deleted. The route still displays the name of the route which was created when an app was created using the cf push command.
So I tried to delete the route using the below command.
It does not allow me to delete using CLI ? Does the app delete command should have taken care to remove the related routes associated with the application ?
Try cf delete-route -h to see the syntax of the delete-route command.
You probably want to run cf delete-route cfapps.io --hostname cf-spring-rested-platypus.
In recent versions of cf-cli you can also run cf delete-orphaned-routes.
I think the reason CF doesn't completely delete the route when you delete an app is so that it kind of keeps the hostname reserved for your use, ie: someone else can't reuse it in another org or space if you've just taken down your app for a refresh. It's kind of annoying when you actually want to reuse the hostname in another space, but considering the multi-tenancy capabilities it kind of makes sense to keep them intact/reserved.
cf delete APP_NAME will not delete the route bound to the Apps and this should not happen first-of-all. Because the router-concept in Cloud foundry is that
One App can have Multiple Routes and Multiple Routes can be configured to one App.
Its Many-to-One mapping. So there is a possibility that the routes you created would still be mapped to another App and it would be as Orphaned-route, only when there are no apps for that routes..
So its a cautious decision and a wise decision too !!
I had few questions that might be easy for others, but that I couldn't wrap my head around.
In developing a "PRODUCTION LEVEL" full-stack web application(node.js/react/webpack),
1) Where do you set up your database? (when developing, I'm using apache couchdb running on my localhost, but when deployed, is cloud database(cloudant) the only solution? or am i missing something?)
2) Is it recommended to deploy my server(node.js) to either digital ocean/aws/heroku, AND set up a third party database else where? (in my case, I'm have to use either Digital Ocean/Aliyun(Chinese Web Service), but they don't seem to have a database package that comes with couchDB) - What is the practical solution for production level application?
3) If cloud database is the practical solution, What Do I do if there is no database storage center for CouchDB located in China? is there a cloud database storage that universally saves all noSQL data regardless of your type of DB? (mongoDB, couchDB, etc.,)
4) AWS/Heroku provides add-ons where you can connect cloud database to my application, does this make the speed of my application faster? For Digital Ocean, it shows article about setting up CouchDB with their service, but does that mean that database will be available for my users to access? or is that just for development purposes
5) Where and How does "Docker" come in to play to help in my situation?
Sincerely,
I cannot say for CouchDB, but I have hosted multiple web applications on AWS using their RDS Database (MySQL). The service you choose (AWS/DO/Heroku), depends on your application and your requirements (pricing etc).
I don't think AWS has a package for MongoDB, but there is a third party service MongoLabs, which can host the MongoDB Database, I bet there would be some out there for CouchDB too.
Or if you cannot get a third party hosting, consider installing the database on your server itself. Getting a VPS from either DO or AWS and setting it up yourself could be an option in that case. The link you mentioned in your last paragraph would help you here. And yes, if you use that and let node connect to it, you can use it just like any other cloud based database, just that it would be on your server.
I haven't used Docker, so cannot say if and how that could help
UPDATE: (reply to comment)
A VPS is a server in the cloud. You don't set up the database on your local computer, no one can access that. You set up your database on the VPS (in the cloud) and then everyone can access that.
A VPS is like your own clean copy of server (ubuntu/fedora) in the cloud, so you can pretty much do anything on it, like your local computer. So basically your database would also be in the cloud.
There are actually 2 ways you could do that.
Get a VPS, install your database and set up your node.js server on the same VPS. Your node application would access the database on the same VPS.
Get a VPS specially for the database, and set up your node.js on another VPS, this would separate the database and node app on two different servers.
To answer part of your question... if you set up a CouchDB server on Digital Ocean (or on AWS, Azure, Google Cloud etc) it will be available to your production users, not just you. You will want to set up security/firewall to limit who can access your server of course.
Cloudant provide CouchDb as a service, in other words you would not have to install the software or manage a server.
With Digital Ocean/AWS/Azure/Google it is down to you to manage the virtual server and the database/other software on it. You can install CouchDb on any of these services and you can install both NodeJS and CouchDb on the same virtual server if you wish.
Bitnami have a CouchDb package that you can use to deploy CouchDb on to several of the major hosting companies, which makes the setup process easier.
I see that AWS and Azure have data centres in China, but at the moment Digital Ocean do not as far as I am aware. I hope this helps