I'm new to deploying an app, as this is the first time I've done it. I'm trying to deploy my mern app to an aws ec2 instance with the intention to use mongodb atlas, I'm using a ubuntu 20.04 server.
I'm following this guide https://keithweaverca.medium.com/setting-up-mern-stack-on-aws-ec2-6dc599be4737 and I've got to part after I've pulled my github repo to the ubuntu server, everything is working up to yet, I skipped the mongodb section of the guide, as I have already created a mongodb cluster.
I'm not sure what to do now, my repo folder is split like this...
- frontend
- build
- public
- src
- Components
- images
... other files in src
- package.json
- backend
- server.js
- models
- routes
- package.json
... a few other irrelevant files (node_modules, etc.)
Although the guide doesn't say to, don't I need to run 'npm run build' in the frontend directory? after I've ran 'npm install'?
If so, my code isn't compiling and I'm not sure why, it says there is a memory leak, and javascript overload.
I know this is a lot of questions, without much detail, but I don't even understand this well enough to give more info. Any questions please ask. I just need to know what commands to run after I've pulled my code from the github repo.
Related
I've been experimenting with single-spa for a while, and understand the basics of the developer experience. Create a parcel, yarn start on a unique port, add the reference to the import map declaration, and so on. The challenge with this is that as my root-config accrues more and more modules managing ports and import-maps starts to get tedious. What I want is to publish these modules to a central repository and load them from there (e.g., http://someserver.com/repository/moduleA/myorg-modulea.js, etc.).
I was recently introduced to localstack and started thinking maybe a local S3 bucket would serve for this. I have a configuration where builds (yarn build) are automatically published to an s3 bucket running on localstack. But when I try to load the root config index.html from the bucket I get the following JS error:
Unable to resolve bare specifier '#myorg/root-config'
I can access the JS files for each parcel and the root-config just fine via curl, so I suppose this would be a problem with any http server used in the same way. I can flip the root config to use the standard webpack-dev-server instead (on port 9000) and it works okay. So I'm guessing there's a difference between how a production build resolves these modules vs. the local build.
Has anyone tried something like this and got it working?
I had a similar issue that I got to work with http-server by adding each child .js file to a sub-folder in the root-config directory and launching the web server at the root-config directory level.
"imports": {
"#myorg/root-config": "http://someserver.com/root-config.js",
"#myorg/moduleA": "http://someserver.com/modules/moduleA/myorg-modulea.js",
"#myorg/moduleB": "http://someserver.com/modules/moduleB/myorg-moduleb.js",
"#myorg/moduleC": "http://someserver.com/modules/moduleC/myorg-modulec.js",
}
Note: By default, Single-SPA has an "isLocal" check before the current import mappings. You'll need to remove this if using a production build or it won't load the correct mappings.
<% if (isLocal) { %>
In my case, I was using localhost instead of someserver so I could navigate into the 'repository' folder and run npx http-server to get everything to run correctly.
I was hung up on this for a little while so hopefully this leads you in the right direction.
For the record, after trying several approaches to hosting a repository as described above, I found the unresolved bare specifier problem went away. So I have to chalk that up as just not having the right URL in the import map. Measure twice, cut once.
I'm trying to take my first baby steps with podman (instead of Docker) and Google Cloud Run. I've managed to build an image with a gcr.io tag and push it to Google. I then create a new service, and I can select the image in the "Select Image URL" pop-up dialog. But then the service fails to start, saying "Image [full name] not found".
I can't find anything on Google's support pages, or anywhere else. I can pull the image, I can push new versions, and they appear on the pop-up dialog. But the service still reports that they can't be found.
What am I doing wrong?
Edit in answer to DazWilkin's questions below:
Can you run the podman-created container locally using Docker?
I can't run Docker locally because it is not compatible with Fedora 31 (hence podman). But I can run it locally using podman run
Can you deploy a Docker-created container in Cloud Run?
As above: F31. However podman is supposed to be a drop-in replacement.
Is the container registry in the same project as Cloud Run?
Yes. I did have a problem with that, but I got a permissions message rather than "not found".
Have you tried deploying via gcloud rather than the console?
Yes.
$ podman push eu.gcr.io/my-project/hs-hello-world
Getting image source signatures
Copying blob c7f3d2e0289b done
Copying blob def7032cea8e done
Copying config f1c2e2615f done
Writing manifest to image destination
Storing signatures
$ gcloud run deploy --image eu.gcr.io/my-project/hs-hello-world --platform managed
Service name (hs-hello-world):
Deploying container to Cloud Run service [hs-hello-world] in project [my-project] region [europe-west1]
X Deploying... Image 'eu.gcr.io/my-project/hs-hello-world' not found.
X Creating Revision... Image 'eu.gcr.io/my-project/hs-hello-world' not found.
. Routing traffic...
Deployment failed
ERROR: (gcloud.run.deploy) Image 'eu.gcr.io/my-project/hs-hello-world' not found.
When I used a Google-built container it worked fine.
Update: 5 March 2020
In the end I just carried on with the Google build service, and it works fine. My initial wish for local builds was in large part because a build on Google was taking over half an hour (lots of Haskell libraries to import), but now I've figured out how to use staged builds and multi-processor VMs to avoid this. I appreciate the efforts of those who have tried to help, but right now it's not broke so I'm not going to try to fix it.
I had the same issue: it seems Cloud Run is picky about the kind of manifest it can pull.
By building my images with --format docker and pushing them with --remove-signatures (inspired by this issue), podman will create and push docker-style manifests to the Container Registry and everything ran smoothly!
Too bad I spent a lot of time thinking it was a lack of permissions problem
I had the same error. My issue was that I was using the docker/setup-buildx-action in a GitHub action. When this was removed, Cloud Run was happy with the resulting manifest / container image.
Thanks to #André-Breda for providing the direction.
I've been having the same issue today. I'm using buildah to create the new image. I realized that the image I used successfully yesterday was built as root. So I built the new one as root and pushed it successfully.
Wish I knew why. The images built as my username ran fine locally with rootless podman.
Edit:
Summary, I tried to follow only the steps listed in the below two links as applies to windows:
https://github.com/mapbox/mapbox-gl-js/blob/master/CONTRIBUTING.md
https://github.com/stackgl/headless-gl#windows
Here I have reattached the screenshot of the commands that I had problems with:
https://imgur.com/RCQCNU5
One more step I took that I should mention is I also did not find the headless gl when I downloaded the repository, when the install headless gl command did not work I manually copied the file and put it in my local copy under the nodemodules directory thinking it would work but it didnt solve anything. I do think this is related to access issues but I dont know what else I should try to get it working?
First, let's clarify your problem: you want a version of mapbox-gl.js which contains a recently fixed bug.
Your best option is to just wait a couple of weeks for a release.
Failing that, you should build your own, from master. You don't need to set up a debug server for that. You can skip straight to the "Creating a Standalone Build" section.
If the steps for building on Windows don't work for some reason, you could set up a local virtual machine running Ubuntu and use that.
But honestly, just wait a couple of weeks. :)
Just in case some one else need to run this on local server.
After clone
Run npm install
npm run start-debug
It will start listening on port 9966.
Test the debug html files entering to
localhost:9966/debug/FILE_NAME_TO_TEST.html
I am attempting to deploy an angular app into IBM Cloud - Cloud Foundry using the CF CLI.
It always seems to fail and doing some research it requires a node script for the start command in package.json. Therefore it is failing due to me having a Ng serve command.
Any ideas about getting around this issue?
So after having a play I realised that the research that I have done is misleading and I have finally figured it out now. Thought that I would post my findings here to save someone else the trouble:
Firstly, unlike doing a ng serve locally, you will need to build the project first i.e npm run-script build. This should give you the dist directory.
Secondly I had a slightly invalid manifest.yml. This is a sample of the file that I have used which finally got it to work:
---
applications:
- name: <App Name>
path: dist <- This points to the compiled code
random-route: true
Hope that this helps someone in the future.
I have database migrations (with sqlalchemy-migrate) working well in my dev environment. However, I'm a little stumped about how to integrate this into my deployment process.
I'd like to use fabric to execute the manage.py file on the remote server but I'm not sure what to use for the repository value in this file. Referring to both 'appname/migrations' and '/usr/local/pylons/appname/env/lib/python2.6/site-packages/appname-05.egg/appname/migrations/'
both fail with a migrate.versioning.exceptions.InvalidRepositoryError
Does anyone have a fabfile and manage.py that plays nicely with sqlalchemy-migrate?
What I did was to generate a manage.py file per the sqlalchemy-migrations docs. In there I hacked it up to load our config information which includes the db auth info. In our case it's a Pylons app so it reads the proper Pylons config.ini file.
http://readthedocs.org/docs/sqlalchemy-migrate/en/latest/versioning.html#project-management-script
Then the fabric commands all interact with the manage.py file vs using the Python API directly. Since everything, from the SA-Migrate manage.py through the app itself I don't run into any sort of path issues like you mention.
Not sure this is a 'exact' fix but maybe helps.