The way we currently setup web app for new customers is this: I deploy app on subdomain1.example.net for a user. I create a newfolder1 on /var/www/newfolder1 and pull the project from git. create database1 in phpmyadmin. create new env file in newfolder1 to connect with database1 and update virtual host. When new customer comes we repeat this process manually.
Is there an easier way to do this? We also want to be able to allow users to dynamically create their own instance of the app from our website. I looked for tutorials, but couldnt find any. Thanks.
Related
I am using Firebase for a long time (since 2018) and loving it. In that time there was not Location southamerica-east1 (São Paulo). Now I would like to store the project (web app, cloud function, and database) in southamerica to reduce cost and make it near to my end-users (also based in Brazil).
I have source control, all environment parameters values stored in Custom Environment Variables. The application works fine when no data is found. No concerns with backup data. No problem about downtime. This is not a critical app.
Anyway, I can't delete the application because I already have some users logged in there and IoT devices sending data through PubSub.
How can I rebuild my Firebase/Firestore/Web application/Function from the ground up, and make sure the new location is southamerica? If possible, I need to keep user and passwords, and web
Looking forward, (I don't think moving the bucked location would be the best solution here) but based on this page Select locations for your project I can't update the location, but since it is based on bucked location, if it doesn't break the project, I will use Google Cloud Transfer Page to Moving and renaming buckets
May is it a better solution than rebuild the app (Firebase/Firestore/Web application/Function)?
May I break my Firestore database or cloud function or web app?
May I lost my project domain or any other related URL parameter like authDomain, databaseURL, storageBucket?
May I need to update some web app parameter after the change?
They cannot be moved at present and migrating data is a manual process. Difficulty varies by product.
General guidance
Do not delete the old project before fully migrated.
Hosting
This migration is nearly trivial, with the understanding that there is likely a minor service interruption while moving custom domains.
Deploy to the new site
CNAME your custom domain to the new site (myproject.firebaseapp.com)
Delete custom domain from old site
Add custom domain to new site
Cloud Functions
This migration is trivial.
Create a local directory for your new project
Run firebase init and set up project normally (enable Functions)
Copy your Functions code into the new project's functions/ directory
Deploy to the new project
Database
This migration is tricky, difficult, and highly specific to your use case and tolerance for downtime. What follows is a general template to adapt.
Reference docs for import/export: Firestore import/export, Realtime Database backups
In the old project:
Lock the database using security rules to prevent changes
Export existing database
In the new project:
Import the database backup
You probably need to migrate existing users (see account export/import) as well so user ids stored in your DB will still reference the correct accounts
Point existing apps to the new project
If downtime is not an option, or if you'll be deploying a new mobile app version and need time for changes to propagate, then you'll need to set up a dual write model:
Dual sync: Create a Cloud Function on both the new and old database that duplicate all create/update/delete operations on the respective partner endpoint.
Sync pre-existing data: Perform the export/import process as above on all data created before the dual sync was implemented, excluding the step to lock the old database
Shut down your old mobile app version (once enough accounts have migrated)
Shut down the dual sync Functions and turn down the old site
Based in your information, the main issue is Firestore because other products are globally balanced like Cloud IoT Core and Hosting (these can't be configured on a specific region)
Other products like Functions can be redeployed with the same code and name into another region.
I think that you can create another project only to move the database to the new region and configure all Cloud resources to reach the new located database.
As a caveat, you need to add another domain/subdomain and create new credentials to work with the new project; this step can´t be skipped because it is required for authentication.
On the application side you can add the access to the new database
In case you need assistance during your migration you can start a case with GCP/Firestore support.
This is a hard pill to swallow, but maybe the costs and the time to migrate to another region will be higher than keeping your application as is working today.
I just created a new DACPAC project and imported a DB. A file was created with these contents:
CREATE LOGIN [Processing]
WITH PASSWORD = N'adsf&^*lajdf', SID = 0x..., DEFAULT_LANGUAGE = [us_english], CHECK_POLICY = OFF;
Should a DACPAC create a server login? A teammate suggested that this file be deleted, but I don't want to do that if it should remain.
The question is a bit unclear, however I'll try to answer. DACPAC has everything, it will contain all database objects as well as logins and users, however you can control what exactly should you deploy by setting all needed settings via publish profiles.
Another point is that handling users and logins with SSDT is usually bad/complex idea mainly because you have different environments with different sets of users, their permissions and so on. So if you are not going to maintain users and logins via project then I agree with your teammate that it should be deleted from the project.
So, basically you need to ask yourself why do you want to have this user/login in the project.
My preview works and has data but my deployment has no data. I'm using the (Recommended) DEFAULT CLOUD SQL database configuration.
Note: This is only day 4 with Google App Maker. Finding answers to App Maker-specific questions has been super difficult, but I'm making rapid progress on my application, so overall tired but good. :{)
As written in the documentation,
App Maker deployments can use the same Cloud SQL instance, but have separate databases on that instance. Data that you had in preview mode is not available in other deployments. You have a few options for how to handle this situation:
To use data from the preview instance in your published deployment, export the deployment data from the preview instance and import it to the published deployment.
To share a database across all deployments (preview and published), use a custom Cloud SQL database.
When you deploy your app, AppMaker create a new database in your google cloud SQL instance for the deployment. All the data create in previews is in another database.
To use the same database as the preview mode you have to go in the settings of your app in the tab "DATABASE" and copy the Database Key. Then go to your cloud sql instance in google cloud platforme and on the details of the instance in the overview tab just copy the instance connexion name.
then edit your deployments and select "Use Custom Cloud SQL database" and copy with the format
"instanceConnexionName/DatabaseKey" then save and appmaker should ask you to enter you username and password of your google cloud sql insatnce.
On app settings, database page you should see
Databas key: iTIJQaCj491a4111
(Actually this is the name of the mySQL instance)
In GCP console, go to SQL, click on Instance ID, and on the Instance ID overview page is the instance connection name, e.g., MyProject-123456:us-central1:instancename
Back in app settings
Select Switch to custom database and enter the full connection string
projectname:instancename/schema as
MyProject-123456:us-central1:instancename/iTIJQaCj491a4111
Provide username and password
and follow the steps to confirm existing database
Turns out the issue is when you publish it doesn't push the data, you have to manually re-upload the data into the live version. This is actually a good thing, but I wish it'd been explicitly documented. I found it, after figuring it out on my own, in some early release notes from a few years back. I guess I wasn't the only one this stupid.
After I create an app with App Maker, can I let someone copy that file and install it on a different Google Enterprise Account (i.e., a different domain). The question assumes the Domain Administrator would want this and approve it.
Definitely, you can easily export app as zip file on one domain and import it on other one. Just go to Menu -> Export (.zip):
The story about data associated with app deployments is little bit different. You can read more about this topic in official App Maker documentation:
https://developers.google.com/appmaker/models/import-export
on meteor i've just added a new feature to download some image in public/img/aSpecificFolder.
It works locally, but i've seen that each time i deploy on meteor.com using deploy command, it looks like that public folder is completely erased. Or maybe that the deploy remove the current app and install a new one. So it only keept the connection to db but all files are removed and put again.
What is the good way of doing if i want to store image on meteor.com ?
thanks
Have you considered using something like collections-fs. When you deploy on meteor it will clear your previous app and use the new one.
If you use something like collections-fs it lets you store your files in the mongo database instead, so they're not actually on the same server that serves out data.
This is also good in another way (scaling) since each virtual environment that hosts your app is able to access the files. If you store the files statically they will only be accessible on one of the servers.
For the moment meteor hosting (via meteor deploy) uses one server, but its likely it will be scalabale in future.