Elasticsearch on cloudfoundary - elasticsearch

I am trying to deploy my asp.net core 2.2 application using buildpacks on SCP cloudfoundary. My application has dependency on elasticsearch. How can I assembly my buildpack file so that I can install both my dotnet core 2.2. app along with Elasticsearch running as a service.
Thanks,

I don't think you would want to run Elasticsearch as an app on Cloud Foundry because it would be difficult to persist any data. The file system your app gets on CF is ephemeral, and is scoped to the lifetime of your app instance. Thus if your app restarts anything you've written to disk is gone. If that doesn't matter to you, I suppose you could proceed.
That said, you wouldn't want to run it as part of the same app. You'd want to push them separately as two different apps. That way you can scale them separately, if one crashes, you don't lose both, and you have dedicated memory limits for each app (i.e. one of the two, cannot consume more than it's share of memory and crash the app).
Having said all that, my suggestion would be to run cf marketplace and see if there is a Elasticsearch service in your Marketplace. That would be the easiest way forward. You could simply cf create-service and make your Elasticsearch service.
If there isn't one in your marketplace, then you can look at getting one through AWS/GCP/Azure or some other provider. Then you can create a service instance in CF with cf cups (it's called a user-provided service). You can bind this user-provided service to your app just like a service created through the marketplace.
If all else fails and you can't find a service from a provider you trust, you could always run your own. Then use a user-provided service to pass in creds.

Related

Debugging locally service that accesses backend database

Our cloud-deployed app is composed of (simplified):
A web front-end
Some back-end services
A database
When developing the front-end, I can easily debug by running the front-end locally, and redirecting its back-end calls to the actual services, since their endpoint routes are public.
However, I also want to debug back-end service code, together with the front-end. I can run back-end services locally, but they can't access the database, since the database doesn't have any publicly-accessible endpoint.
Question: How can I conveniently develop the service code? I can think of these options:
Expose the database publicly, maybe just the dev env's database. This doesn't sound like a good practice security-wise, and I haven't found a way to do it in my cloud platform (CloudFoundry).
Test everything using local unit- and component- tests. We do this, but can't cover everything, and certainly not the integration with the front-end.
Deploy my code changes to a dev environment, and test that way. This is what we do now, but:
It's a much slower development turn-around that running locally
I can't connect a debugger to the deployed app, so I must debug using logs, which again is slow
We have a limited number of dev environments, and this creates contention for them.
Somehow deploy a replica of the database locally as well, using some kind of test data.
Tech details: For cloud we use CloudFoundry over AWS. My back-end services are written in C# + .NET core 5. Locally, we develop them using Visual Studio 2019 on Windows.
For now, I managed to expose my database locally using an SSH tunnel. Specifically, by running cf ssh [AppName] -L [local_port]:[db_hostname]:[port], with [db_hostname]:[port] taken from the app's configuration, taken by running cf env [AppName].

How to implement auto stop for iddle or inactive applications on Google cloud platform like Heroku does?

Classic approach on GCP is rent a linux host with static monthly payment. It doesn't matter if your application is not running or users aren't consuming it, you will always pay the static monthly payment. I think this is acceptable for production environments but for development and testing not.
This does not happen on Heroku :
If an app has a free web dyno, and that dyno receives no web traffic in a 30-minute period, it will sleep. In addition to the web dyno sleeping, the worker dyno (if present) will also sleep.
Free web dynos do not consume free dyno hours while sleeping.
Question
How stop or delete app on google (gae, cloud run, cloud build, containers) if does not receive web traffic?
If it is possible using just google tools it would be great:
https://cloud.google.com/products
Idea
Developing a basic router with nodejs which works as minimal balancer. If web traffic is not detected for some apps, an instruction to google cloud platform api could stop the app or container. This would also apply to other clouds.
Any help is appreciated.
Update
I cannot find any solution yet. I will try to add that feature here https://github.com/jrichardsz/http-operator or a basic shell script to detect incoming request to a specific port like How to print incoming http request on specific port
GCP is offering several serverless products (like you mentioned) and they offer a pricing where you are only charged for the resources you use (when requests are processed).
In Cloud Run you are only billed when an instance is handling a
request using the autoscaling to know more. See their pricing as well for a better overview.
For Google App Engine the app.yaml configuration file contains several settings you can use to adjust the trade-off between performance and resource load for a specific version of your app. You
also check this link how to manage the auto scaling settings.
You can also check this Google Cloud blog for other strategies in auto scaling your applications.
To answer the Comment below:
This video can help you better understand their differences to be able to see the appropriate service for your use case.
To clarify, there's 2 variations of cloud run, the first is managed by google and the other runs on gke. As long as your classic application (api app) is stateless, you should be able to deploy it as a container and take advantage of being charged based on only the resources you use. Snippets would fall under Cloud function where it only runs functions based on triggers.
You can choose to deploy your Cloud Run app on fully managed infrastructure ("serverless", pay per use, auto-scaling up rapidly and down to 0 depending on traffic) or on a Google Kubernetes Engine cluster.
It is also possible to run Docker containers in Serverless using App Engine (Flexible). App Engine is always fully managed, with auto-scaling. App Engine Flex auto-scales gradually and down to 1. App Engine Second Generation auto-scales up rapidly and down to 0.
In your current use case I would recommend to use Cloud Run, check its limitations first before getting started. See the official documentation here and on Cloud Run How-To Guides

How to Test Gol App Engine apps locally on Win 10 and use app.yaml

In Google's latest docs, they say to test Go 1.12+ apps locally, one should just go build.
However, this doesn't take into account all the routing etc that would happen in the app engine utilizing the app.yaml config file.
I see that the dev_appserver.py is still included in the sdk. But it doesn't seem to work in Windows 10.
How does one test their Go App Engine App locally with the app.yaml. ie: as an actual emulated app engine app.
Thank you!
On one hand, if your application consists of just the default service I would recommend to follow #cerise-limón comment suggestion. In general, it is recommended for the routing logic of the application to be handled within the code. Although I'm not a Go programmer, for single service applications that use static_files and static_dir there shouldn't be any problems when testing the application locally. You might also deploy the new version without promoting traffic to it in order to test it as explained here.
On the other hand, if your application is distributed across multiple services and the routing is managed through the dispatch.yaml configuration file you might follow two approaches:
Test each service locally one by one. This could be the way to go if each service has a single responsibility/functionality that could be tested in isolation from the other services. In fact, with this kind of architecture the testing procedure would be more or less the same as for single service applications.
Run all services locally at once and build your own routing layer. This option would allow to test applications where services needs to reach one another in order to fulfill the requests made to them.
Another approach that is widely used is to have a separate project for development purposes where you could just deploy the application and observe it's behavior in the App Engine environment. As for applications with highly coupled services it would be the easiest option. But it largely depends on your budget.

How to setup Application Insights for on-premise Service Fabric?

Is it possible to add application insights for web api that's hosted on the on-premise version of service fabric?
So far I have tried to add the application insights to my project and wondering where to send for monitoring. It was easy when app is also on cloud.
I believe there is no on-premise application insights service, so even if the web api is hosted on-premise over service fabric; one must use cloud version application insights service, is that correct? In that case can anyone let me know how to setup?
App Insights is only hosted in Azure. If you're looking for an on-premise solution, you're best off looking at using something like the ELK stack (Elastic Search, Logstash and Kabana).
Nonetheless, even though your cluster is hosted on-premise, using Asure App Insights is still very much a valid scenario (assuming your IT organisation is fine with it).
Assuming you're fine with Application Insights, I strongly recommend you have a look at App Insights Service Fabric. It works great for:
Sending error and exception info
Populating the application map with all your services and their dependencies (including database)
Reporting on app performance metrics, as well as,
Tracing service call dependencies end-to-end,
Integrating with native as well as non-native SF applications
One thing however that the above won't solve is providing overall cluster health information - e.g. when/how often nodes go up/down, how much CPU/Memory and disk IO is consumed on individual nodes. For this you could try MS EventFlow or a custom windows service
There is no "on premise" application insights, but as long as your on premise service has access to send outbound data, you can use application insights on your site. You won't be able to use some features, like webtests, because application insights wont be able to make calls into your site.
Setup is the same as always, create an application insights resource in azure, and either configure it in visual studio, or manually set the instrumentation key in your applicationinsights.config (or via code) in your app.
If you need to configure outbound firewall rules or anything to let AI send data, that information is all here: https://learn.microsoft.com/en-us/azure/application-insights/app-insights-ip-addresses

How do you run utility services on Heroku?

Heroku is fantastic for prototyping ideas and running simple web services, I often use it to run Python web services like Flask and Django and try out ideas. However I've always struggled to understand how you can use the infrastricture to run those amazingly powerful support or utility services every startup needs in its stack. 4 exmaples of services I can't live without and would recommend to any startup.
Jenkins
Statsd
Graphite
Graylog
How would you run these on Heroku? Would it be best just getting dedicated boxes (Rackspace, e.t.c) with these support services installed.
Has anyone one run utility deamons (services) on Heroku?
There are two basic options. The first is to find or create a Heroku addon to accomplish the task. For example, there are many hosted logging solutions you can use instead of Graylog; Rails on Fire or Travis can be used instead of Jenkins. If an appropriate addon doesn't exist, you can effectively make your own by just running the service on an AWS EC2 instance.
The other alternative is to push the service into being a 12factor application so that it can run on Heroku as well. For example, you could stub out whisper's filesystem calls so that they store in a backing service instead. This is often pretty painful and brittle, though, unless you can get your changes accepted by the upstream maintainers.
you could also use another free service in conjunction with it. OpenShift has a lot of Java related build services and tools that can be added.
I am using a mix of heroku, openshift, mongolab and my own web hosting. Throw in dropbox and box for some space...

Resources