Car-lease-demo in local development environment - hyperledger-fabric

The Car-Lease-Demo seems to be a perfect demo to understand Hyperledger Fabric. However, it seems to be configured to run in IBM Cloud, is anyone successful in running it locally?

I presume that you are referring to this demo. I have not tried this, but it should be possible to run all of this on your laptop. First, follow the directions for running one or more peer instances (and a CA) here. Then, you should be able to run the demo server after a few tweaks.
Looking at the code, you'd have to set some environment variables (VCAP_APP_HOST and VCAP_APP_PORT) to run the node app locally, as these will not be provided unless running in a Cloud Foundry environment.
Further, you'll need to change Server_Side/configurations/configuration.js to provide appropriate values for config.api_* as those values are also specific to the IBM Blockchain service running in Bluemix.

Related

Is Terraform possible to use for local development?

I would like to use Terraform for the infrastructure of my project and am starting to look into it for local development. I am brand new to it so apologies if this is a basic thing to know. So far from my research it appears like it is more useful / helpful when deploying it to a Cloud provider. Is it possible to use it for local development such as connecting to local Docker containers or am I better off waiting and using it when I start to set it up in the Cloud?

JHipster Registry - why is it mandatory to run in the cloud for production?

I am working on an app that needs to be self-hosted on a Windows 10 PC where all the clients are inside a company network. I am using docker-compose for the various microservices and I am considering JHipster for an API Gateway and Registry service.
As I am reading the documentation, there is a line in the JHipster docs (https://www.jhipster.tech/jhipster-registry/
) that says "You can run a JHipster Registry instance in the cloud. This is mandatory in production, but this can also be useful in development". I am not a cloud expert so I not sure what is different in the environments that would cause the Registry app issues when running on a local PC. Or perhaps there is a way to give the local Windows PC a 'cloud' environment.
Thanks for any insight you have for me.
I think that this sentence does not make sense.
Of course, you must run a registry if you generated apps with this option but it does not mean that you must run it in the cloud. The same doc shows you many alternative ways to run it.
Running all your micro services on a single PC is a bit strange, it defeats the purpose of a microservice architecture because you got a single point of failure that can't scale. Basically, you are paying for extra complexity without getting the benefits, where a monolith would be so much simpler and more productive.
How many developers are working on your app?

What's the difference between a web server and a development server?

So a bit of context - I'm trying to give my create-react-app project a backend using express.
I'm following a tutorial that talks about having two servers working concurrently. This leaves me a bit confused - what's the difference between a web and a dev server, and how you can have two servers working simultaneously?
I think the underlying issue here is that I only have a shallow understanding of what a server actually is: I only understand it as being a process that listens to requests and sends responses.
Cheers
The tutorial most likely refers to the following definitions:
development server
available at localhost
runs on your local machine, i.e. your PC
intended for local development and testing
web server
available at an IP adress or domain
runs on a remote server like a cloud server such as Google Cloud / Heroku / Digital Ocean
intended for production for your real users
From what I understand of your question, this tutorial seems to be talking about 2 separate environments, a production environment (i.e. where the 'real' code that clients/users will use runs), and a development environment (i.e. where code that is currently under testing and not ready for the 'real world' runs).
The reason you want (at least) 2 of them is so you can deploy your code to the dev environment and then test it out, see if it works, how it works, and if it breaks anything, without risking the real server going out, or maybe accidentally wiping your real customer database or something like that. When you deploy to your dev environment and see that everything work as it should and nothing is broken, then you can put that version of the code to run in your real, production environment, and be pretty sure your backend is not gonna go out while you are developing
I may be misunderstanding what the article is saying, but from your description I think that is it
Hope that helps you!

Using Docker to replicate a flask app set up?

I have not used Docker before at all, but I have a flask app running on an Azure server right now which I would like the mostly replicate to another server.
Ubuntu 16.10
Anaconda for my Python environments
A few systemd files to configure nginx and uwsgi
My goal is to start fresh without having to do a fresh install of the OS (I do not have the ability to do this) on my current server. I have a few issues with environments and multiple Python versions which I would like to escape from.
I would then like to take this set up and send it over to another server which is completely fresh (a brand new Azure instance which hasn't been touched yet). Is this possible with Docker?
To make things clear, Docker is not a technolgy to migrate applications from one server to another. Docker is a "vitualization" technology which allows you to isolate applications when they are running. Once you have this isolation, the Docker containers can be migrated to any server having just Docker installed. Thus you releive yourself from issues like "It works on this machine, but it doesn't work on that".
In order to do that, you need first to Dockerize your application. Your requirements are very common, and there are many samples online of how to containarize such applications.
However, you need first to learn about Docker to get started (which need a couple of hours/days). You can start learning about Docker here. Once you have your application dockerized and working on one machine, moving it to another server is a piece of cake.

Deploy node.js in production

What are the best practices for deploying a nodejs application in production?
I would like to know how deploy for production Api's nodejs is being done today, today my application is in docker and running locally.
I wonder if I should use a Nginx inside the container and deploy my server on it or just upload my image node that is already running today.
*I need load balance
There are few main types of deployment that are popular today.
Using platform as a service like Heroku
Using a VPS like AWS, Digital Ocean etc.
Using a dedicated server
This list is in the order of growing difficulty and control. So it's easiest with PaaS but you get more control with a dedicated server - thought it gets significantly more difficult, especially when you need to scale out and build clusters.
See this answer for more details on how to install Node on a VPS or a dedicated server:
how to run node js on dedicated server?
I can only add from experience on AWS using a NAT Gateway which is a dedicated Node server with a MongoDB server behind the gateway. (Obviously this is a scalable system and project.)
With or without Docker, you need to control the production environment. This means clearly defining which NPM libraries you will need for production, how you handle environment variables and clusters for cores.
I would suggest, very strongly, using a tool like PM2 to handle clusters, server shutdowns and restarts and logs. (Workers & slaves also if you need them and code for them).
This list can go on and on, but keep in mind this is only from an AWS perspective. Setting up a Gateway correctly on AWS is also not an easy process. Be prepared for some gotcha's along the way.

Resources