I'm currently working through my first AWS Mobile Hub project, and it's going pretty well so far. However one thing which is unclear is how "production" deployments are managed.
My Mobile Hub project is using features including:
Sign In (Cognito)
NoSQL Database (DynamoDB)
Cloud Logic (API Gateway & Lambda)
Is there any way to make a distinction between a "development" and "production" environment?
For example, maintain a separate "Users" DB for development and production, and if so, how would i configure the app code (React Native) to know which DB / environment to talk to.
Similarly for API Gateway, i can see that it has created a "Development" stage, but it's not clear whether i should be pointing my production iOS/Android build directly at this Development stage, or if i should be deploying a "production stage", and again, if so, how would i integrate this environment specific switching login in my app code.
Thanks in advance!
I don't know if there is a simple distinction but there are some options I have seen in the docs.
Detach from existing awsmobile project
awsmobile init --remove
Attach to new existing awsmobile project
awsmobile init <awsmobile-project-id>
Track the ids of the environments when you deploy.
Mobile ID
https://console.aws.amazon.com/mobilehub/home?region=us-east-1#/[awsmobile-project-id]/build
Related
Please understand that I am using a translator because I can't speak English.
I want to use Strapi to configure API Server, receive APIs using Nextjs, and create a website that expresses news articles.
News articles are registered daily using the Strapi management panel, and Nextjs should reflect them in real time.
Next.js will also include the ability for users to register, modify, and delete posts. (Board)
Also, in the Expo React Native App, data must be received from Strapi to the API and displayed.
Cloud services must use AWS.
In addition, after development in the local development environment, it must be reviewed by the customer at the test server and updated to the production environment after that.
Therefore, I think we need at least two management servers.
S3 and RDS should also be used.
It's not a very large site.
There are not many users yet.
If I need a docker, I will use it.
Frontend(Next.js)
Amplify
Docker -> App Runner
Docker -> Fargate
EC2
Backend(Strapi)
Amplify
Docker -> App Runner
Docker -> Fargate
EC2
Help me Please!
I have an AWS AppSync API (maybe like 80% done) and I'd like to create environments for staging, development, production, etc. My initial googling led me to using Amplify to create environments but I didn't see anything about making environments for existing APIs. I've been using the console to develop the API (in case this detail is important). I'm new to using AWS so I'm not really sure what to look for but my question is how do I create different environments for my existing AppSync API?
I am currently looking into AWS Amplify as well as I am reading Serverless Stack. My goal is to create a simple ToDo list app. Both "Getting started" / Documentations seem to have the same goal. However, AWS Amplify guide seems to be way easier from the setup.
And that's where I am confused. As far as I understand AWS Amplify also uses DynamoDB and gets data via GraphQL. But where is the difference between these two documentations?
Serverless Stack is a resource providing guidance on how to create serverless applications with AWS. It was created by a company called Anomaly Innovations.
AWS Amplify is an open source framework maintained by AWS which helps developers integrate their applications with AWS resources.
AWS Amplify is a very confusing service and consists of many components. I would categorize as follow.
AWS Amplify Console
AWS Amplify CLI
AWS SDK&Libraries to integrate to your mobile or web
AWS Appsync Transformer
AWS Amplify Console gives you the ability to easily to setup Continous Deployment for your Amplify project. Amplify Console use together with AWS Amplify CLI for you to manage different environments.
Let's say you want to start the Todo App. You start on your local using Amplify CLI and create API Gateway/Lambda/DynamoDB stacks.
Amplify CLI lets you create the whole stack easily and push it to AWS to deploy the whole stack. Then you can create a different environment based on the same stacks, let's say you want your dev environment, and QA environment and production environment.
Amplify CLI gives you all the commands necessary for you to achieve this, then if you want to auto-deploy the change to AWS when someone push the code to your Git repository, you can use the Amplify Console to set up exactly that.
Amplify Console also integrate with AWS Domain so, you can easily point your own domain to any of the environment.
On top of these, Amplify also provides, GraphQL Transformer, which you can easily define the GraphQL schema in Amplify format and it will transform and deploy to AWS Appsync. And there is a Mobile SDK which you can sync data between AppSync and you're mobile and provides some UIs as well.
We used one of our web projects and we liked it for Continues Deployment aspect of the Amplify, but we didn't like the AppSync(GraphQL) aspect of Amplify just b/c it was not easy to implement layered resolver.
Also, keep in mind that Amplify CLI/SDK/Transformer is under one project and it's still very fragile. You can take a look at the version history from https://www.npmjs.com/package/#aws-amplify/cli and you will see few version bump just in a single month. There were many obvious bugs we encounter, even on the AWS Console.
I haven't use the Serverless yet, but as long as I know, Serverless provides No1 and No2 of Amplify with greater stability.
I have a React application that I am bundling using Webpack. The app relies on a MongoDB database and a Node/Express server to field the backend of the app (API requests, etc.).
I want to set up continuous integration/deployment (C.I/D.), but am not sure where to start. As my app's GIT repo is with Bitbucket and I have had experience with AWS in the past, it would be good to enable C.I/D. using these. How do I go about this?
You can use Jenkins to build your project from BitBucket.
Make use of AWS CodePipeline and AWS CodeDeploy for continuous delivery on AWS.
Jenkins gives you the flexibility to work with any source control system, and has plugins for AWS CodePipeline.
From AWS CodePipeline, you can configure a stage to call a Jenkins build job.
I've been using this system in production for quite some time now, without any issues.
I'm attempting to move an App Service from one service plan to another. When I use the portal to do so, the other App Service plan is not displaying.
Both App Services are in the same Location and Resource Group.
The two App Services Plans are in the same location and have the same pricing tier.
I use the "Change App Service Plan" option for the web app. The only App Service Plan that is displayed is the current one. There is also a "Create New" option.
So, in summary:
1) Why is the other App Service Plan not able to be selected.
2) How can I move the App Service (Web App) to the other App Service Plan.
The reason why you are not able to see the other App Service Plan when you try to change the App Service Plan is due to current limitations in moving the Azure web app resources.
The other App Service Plan which you intend to move your Web Apps to is in another resource group with existing Azure Web Apps, which is not supported currently
Azure Web Apps current move limitations updated 01/04/2016
Hope this answer your question.
Not sure if it is something recent, but it seems it is finally possible. The option is in the main resource menu as "Change App Service plan". See:
I was able to move an app service(website) and also its deployment slot to a different plan (with same parameters and location - but did not try if this is a requirement).
Yes, we can now move the App Service Plan using the Change App Service Plan.
But sometime you will get No App Service Plan Found as this is the known restriction for the moving App Service plan.
Restrictions
We can move the App service plan only if the new plan is in the same resource group and geographical location.- These two conditions is is to ensure the new plan is in same webspace
Webspace
Azure deploys each new App Service plan into a deployment unit, internally called a webspace. Each region can have many webspaces, but your app can only move between plans that are created in the same webspace. An App Service Environment is an isolated webspace, so apps can be moved between plans in the same App Service Environment, but not between plans in different App Service Environments.
You can’t specify the webspace you want when creating a plan, but it’s possible to ensure that a plan is created in the same webspace as an existing plan. In brief, all plans created with the same resource group and region combination are deployed into the same webspace. For example, if you created a plan in resource group A and region B, then any plan you subsequently create in resource group A and region B is deployed into the same webspace. Note that plans can’t move webspaces after they’re created, so you can’t move a plan into “the same webspace” as another plan by moving it to another resource group.
You can find this in the official doc here and here
You can also refer this SO
You can configure a backup and restore on the new App Service under the new APp Service Plan.
Backup an app: https://learn.microsoft.com/en-us/azure/app-service/manage-backup#:~:text=The%20Backup%20and%20Restore%20feature,or%20restoring%20to%20another%20app.
Put your code in DevOps and deploy it to the new service plan and point DNS.
thank you for the tips
i found a work around. you can move app service plan to the same resource group, and then you can move apps from one plan to another.
Move resource first will do a check, after that you can review and finally move.