We build a NextJS application using Github actions and ship it to an EC2 machine. There it's run by PM2 using an ecosystem.config.js file. PM2 supports passing env variables, but it doesn't work using basic setup because of the way NextJS handles them - substituting them by actual values during the build.
Is there a way to provide them when an application runs instead of when it's being built?
Related
I am working on ASP.net project in which I have defined some environment variables and I am fetching it in Startup.cs
Environment.GetEnvironmentVariable("InstanceName")
When I run this project on windows, it works as expected. But when we deployed to AWS Linux server, it is not reading env. variable correctly.
Is there diff. way on Linux to handle env. variables?
Good day everyone.
My issue is the following. We use a NextJS app with SSR as the Frontend for our services. We want to deploy everything on AWS App Runner via docker images. Locally the frontend container registers all env variables we have in .env.local but on App Runner all env variables turn out undefined
Of course, we don't want to use an .env file for production. We set up all env variables in the config service of App Runner and we use the NEXT_PUBLIC prefix as we should with SSR. But still nothing.
Does anyone have any suggestions on how to proceed from here?
I have a number of tests in my project which are run as part of the build. Some of those tests are integration tests which need a username/password set of credentials in order to run the tests.
I want to keep these credentials out of the source code so on my local machine I have set them up as user secrets and on the server they are environment variables. The deployments are working just fine with this arrangement.
My problem is running the tests as part of the build. The tests are not being fed with any login credentials and therefore are failing with authentication issues. How do I supply these values without adding them to the appsettings.json files?
I am running a dotnet core project and have a standard Azure DevOps build template.
Thanks!
Non-secret variables declared in the build are automatically turned into environment variables on the build agent.
Secret variables are intentionally not turned into environment variables, but you can add a Command Line or Script task that's appropriate for your platform (Bash, Powershell, whatever) and set an environment variable by passing your secret in as a parameter to the script.
We are an ASP.NET shop using Windows Server, IIS, Octopus Deploy, etc. We do not use Azure.
In terms of structure and files, my Angular 2 app is very similar to this: https://github.com/DeborahK/Angular2-GettingStarted/tree/master/APM%20-%20Final%20Updated. There is no .sln file or anything like that as it is not an ASP.NET app.
What steps should I take to deploy my Angular 2 app to a server?
My guess so far is to just to run these commands on the server directly from a command window:
- npm install
- npm run lite
Or maybe try create windows service to run these commands?
You will deploy the way you normally do, but eventually what you're going to need to is to create a dist folder (or whatever you want to name it) that has all of your concat'd files / etc. This is what you'll eventually push to IIS etc. Your original Typescript / etc files of course will never get exposed.
How you get your files to a dist is up to you. You can use SystemJS, Gulp, Webpack.
I'd recommend Webpack personally. Basically nothing unusual, you just only want to expose (publically) those minified/concat specific files for Production. IIS just needs to know where they are, and how to serve the initial index.html (Also, up to you, MVC, .NET Core, etc)
I recently created a droplet on Digital Ocean, and then just used Meteor Up to deploy my site to it.
As awesome as it was to not have to mess with all of the details, I'm feeling a little worried and out of the loop about what's happening with my server.
For example, I was using the console management that Digital Ocean provides, and I tried to use the meteor mongo command to investigate what was happening with my database. It just errored, with command not found: meteor.
I know my database works, since records are persistent across accesses, but it seems like Meteor Up accomplished this without retaining any of the testing and development interfaces I grew used to on my own machine.
What does it do??? And how can I get a closer look at things going on behind the scenes?
Meteor Up installs your application to the remote server, but does not install the global meteor command-line utilities.
For those, simply run curl https://install.meteor.com | /bin/sh.
MUP does a few things. Note that this MUP is currently under active development and some of this process will likely change soon. The new version will manage deployment via Docker, add support for meteor build options, and other cool stuff. Notes on the development version (mupx) can be found here: https://github.com/arunoda/meteor-up/tree/mupx.
mup setup installs (depending on your mup.json file) Node, PhantomJS, MongoDB, and stud (for SSL support). It also installs the shell script to setup your environment variables, as well as your upstart configuration file.
mup deploy runs meteor build on your local machine to package your meteor app as a bundled and zipped node app for deployment. It then copies the packaged app to the remote server, unbundles it, installs npm modules, and runs as a node app.
Note that meteor build packages your app in production mode rather than the debug mode that runs by default on localhost when you call meteor or meteor run. The next version of MUP will have a buildOptions property in mup.json that you can use to set the debug and mobileSettings options when you deploy.
Also, since your app is running directly via Node (rather than Meteor), meteor mongo won't work. Instead, you need to ssh into the remote server and call mongo appName.
From there, #SLaks is right about how it sets things up on the server (from https://github.com/arunoda/meteor-up#server-setup-details):
This is how Meteor Up will configure the server for you based on the given appName or using "meteor" as default appName. This information will help you customize the server for your needs.
your app lives at /opt/<appName>/app
mup uses upstart with a config file at /etc/init/<appName>.conf
you can start and stop the app with upstart: start <appName> and stop <appName>
logs are located at: /var/log/upstart/<appName>.log
MongoDB installed and bound to the local interface (cannot access from the outside)
the database is named <appName>