I have a django app which i run from my virtual environment on my localhost and in that virtual environment i made some changes to django admin panel's html source code but when i deploy it to heroku. it installs another django with pip and doesn't run from the virtual environment i made changes to resulting into the loss of the changes i made.
You should extend the templates and not hard-code overwrite them. Checkout this SO answer to see some ways to do that.
Related
We have a Vue app hosted as an Azure App Service. Under Settings\Configuration in Azure Portal We have added application settings like VUE_APP_API_ENDPOINT_URL. These become environment variables like the documentation explains, and can be verified by opening a console from the portal and type 'env'.
I Had hoped that These env variables would now be accessible inside Vue by use of
process.env.VUE_APP_API_ENDPOINT_URL
My guess is that its only becomes available in VUE when aplication is build with WebPack or similar.
At least it doesn't work.
Are there any nice way to read those env variables created from Azure App Settings into the vue app?
Some people mentions dotenv npm package, but we need to read the env variables not add them from a config file.
You would be correct that the Environment Variables only become available when you build the application. And to elaborate on that, only the Environment Variables that you specify/supply at build time are the ones that become available in the application from the build process as per the documentation here:
https://cli.vuejs.org/guide/mode-and-env.html#environment-variables
Specifically look at this:
Note that only NODE_ENV, BASE_URL, and variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. It is to avoid accidentally exposing a private key on the machine that could have the same name.
I was struggling to accomplish essentially the same thing that you're trying to accomplish. I was trying to get a value from Azure's Application Settings so that I could setup multiple environments for my application and not have to constantly change values depending on the environment I published the app to.
After realizing that you might be onto something and reading the confirmation of such in the documentation, I decided to try putting the Environment Variable that I was trying to get from Azure's Application Settings in a .env file with a default so that it would be specified at build time. I then published my app to Azure and tested it and it worked!
Try creating a .env file with all of the Azure Application Settings that you're trying to set with default values or something, like:
VUE_APP_API_ENDPOINT_URL=default_value
And then set those same variables into your Azure Application Settings with the proper values and it should work.
Zoull's comment, while somewhat factual, is not possible. His comment implies that setting VUE_APP_API_ENDPOINT in Azure's Static App Settings blade will seamlessly include that var, and perhaps other VUE_APP_* vars into the vue app.
This is wrong.
Webpack is responsible for inclusion of VUE_APP_* vars into the build, and this is only possible at build-time.
This can be verified by following his logic, and then dumping to console "env" at runtime. Values will be set to, permanently, whatever they were at build-time.
tl;dr: Vue will never read, post-build, vars from Application Settings.
I use Github actions to build and deploy. By adding an env: setting after the with: stanza, and including VUE_APP_* vars there, I can do what OP is trying to do.
I believe I can also set some github "secrets" in githubs settings for my repo, and also include them dynamically in the YAML.
Ex. If I have a github secret key/val of: "VUE_APP_FOO: true", in my github action yml, I can do:
env:
VUE_APP_FOO: ${{secrets.VUE_APP_FOO}}
Then, in my final vue build, I should have a value of "true" when I read the process.env.VUE_APP_FOO var.
Savvy?
I am working for a client that does not allow setting up anything on the native Windows workstation.
I am, however, allowed to set up a virtual machine on which I can install anything I want.
So, I've set up a Linux VM and installed the React environment.
However, I would like to be able to use the native Windows tools that are allowed for development, since installing and using them on the VM is painfully slow.
I'm currently modifying the code with a native Windows IDE, then pushing the changes to a Git repository, then pulling the changes down to the Linux VM to see them work. However, for debugging, where changes are added, removed, modified, etc... this is also painfully slow.
I tried to set up a shared folder to work on the code locally and having it update on the Linux VM dynamically, but that doesn't work because "npx create-react-app" does a bunch of things, like set up symlinks, that either don't work on a shared folder or aren't allowed by IT. I'm guessing it's the shared Windows folder that's limiting this. I also tried to set up a Samba share of the Linux folder, but I think this is blocked by IT, because I just can't see it from my Windows machine, and network discovery is turned on.
So, now that you know my pain, what would be the best way to set up a React development environment in this situation? Help...
I almost understands nothing about linux and VM, but here is something you can do.
When creating a react application with create-react-app, when you run npm start, your application will be hosted in localhost:3000.
So to do what you want, you need to set up the enviroment in the VM (e.g. create-react-app) and then configure (this is the part I don't understand how to do) your VM in a way you can access the VM's localhost and the files of your project.
This way you can edit the files of the VM and also see the app changing in the windows browser.
How to share VM's folder with host
How access VM's localhost
I want to deploy Strapi to my Azure. Anyone here who has an experience doing such and making it up and running completely? Somehow I couldn't find any detailed instructions how to do that in Azure.. I'm looking for something that is as easy as deploying it to Heroku - but it's fine though if it'll require more steps as long as I can make it to work completely.
This is the complete instruction I have also created in the README of the repository.
Strapi-Azure 3.1.3
This is a working repository of Strapi 3.1.3 which you can already deploy as an Azure Web App. This requres a paid subscription, minimum of B1 plan (32 USD estimated), so we can enable the 64-bit platform configuration and the Always On feature.
To get started, let us first create and configure our Azure Web App:
Create an instance:
Name: The name of your choice that is still available
Publish: Code
Runtime staci: Node 12 LTS
Operating System: Windows
Region: select near you
Sku and Size: select B1 (minimum)
Configure the Environment variables:
Add the following key-value pairs:
For the HOST make a ping to your .azurewebsites.net instance and get the IP
Configure the Platform Settings
In the General Settings tab (beside the Application Settings), change the Platform from 32 Bit to 64 Bit
To confirm if you are indeed now on 64 Bit mode, go to Console and run node -p "process.arch"
Install yarn:
Go again to Console and run: npm install -g yarn
Deploy from your github account a copy of strapi-azure repo
In the Deployment Center tab, connect your GitHub account and browse your copy of strapi-azure
Select App Service build service as your build provider
Select repository and branch
Deploy!
Build your Admin UI using Kudu service
Go to Advance Tools -> Go -> expand Debug console from the toolbar -> CMD
Inside the wwwroot directory (site/wwwroot/), execute yarn build
See it in action 😊
It should not be any different than installing Strapi on any VM (Azure, AWS, GCP or even local VM).
Quick start guide should help you setup things and run Strapi server --> https://strapi.io/documentation/3.x.x/getting-started/quick-start.html
Primarily: Install nodejs, npm and strapi (via npm). Execute strapi new cms --quickstart and you should be good to go (with default configuration).
Assuming you have it within a GIT repository, I may have some useful insights.
When I set mine up, I created an app service hosted on windows - for some reason I found the Linux ones very unstable. I then used the Deployment Center to then setup the connection between my repository hosted on Azure Devops onto my App Service. When it deploys IISNode will automatically be setup with an appropriate web.config file for getting a NodeJS server up and running.
You may need to ensure you are running in production (assuming this is what you want), you can set this up by going to the App Service - Configuration - Application Settings (tab) - set up new variable called
"NODE_ENV" and set this "PRODUCTION".
I also found it useful to set
"WEBSITE_NODE_DEFAULT_VERSION" and specify the version - in my case it was "10.15.2".
For the database I used a ComosDB with the Mongo API, this was hosted on azure and it worked OK - the main problem I found was that I was getting charged a lot for the usage of it, not quite sure at this stage how to get around it.
One thing that did catch me out was setting the "port" variable within the config/environments/production/server.json - I was hard coding a port which doesn't work within IISNode - this needs to be set to something like
"host": "your.domain.com"
"port": "${process.env.PORT || 1280}"
You will also need to setup your database settings in config/environments/production/database.json file.
Happy to work through any further points, let me know
I have a Node.js app that I wrote and successfully deployed to a Heroku app via Bash. From my computer running Ubuntu at home it runs fine locally too.
However, I have just cloned the repository to a Windows machine and while I've successfully managed to push updates to the Heroku remote, which work, whenever I run heroku local from Windows and try to access the local version (localhost:5000), that page serves an error and my command line returns TypeError: Request path contains unescaped characters and layer.js:95.5.
The app uses https.get and this seems to be the problem line, locally.
I'm reluctant to try adapting my code since it works fine on Heroku itself and works fine on my Ubuntu machine -- so can only assume that something needs configuring on my Windows machine.
Any idea what the problem might be?
tl;dr
Be careful which variable keys you choose for config/.env in Heroku. Windows has some reserved keys (like user and path) which will mean trying to set your own values against these keys will not work.
The detail
It turns out the issue is with my choice of variable names as used in my .env file.
When you have data that you don't want to commit to a repository (in my case, an authentication key and details for my account) you can add them to Heroku as "config vars" -- key=value pairs which Heroku keeps separate to your code so you can version and share your repository as needed and others can add their own details.
When running Heroku locally however using the heroku local command from the toolbelt, these variables need to come from somewhere else. Heroku's help recommends setting them up as key=value pairs in a file called .env (which you can then add to .gitignore to prevent accidental committing.
Unfortunately, in my case it was my choice of variable keys in .env that caused the problem. I had created dependencies on variables called user and path but these seem to be reserved on Windows and have a special purpose and therefore could not be overwritten by what was in my .env file. This is why what worked for me on my Ubuntu machine would not work directly on Windows.
You can see this in action by calling console.log(process.env.user, process.env.path) from Node on a Windows machine.
Now that I have changed the variable names to something non-reserved heroku local works fine. Calling the programme via node command will still not work as it is not set up to pick up the variables from .env as Heroku.
Hope this helps someone else.
I am new to Jive development using Node.js and I see that any addons that you create must be running and reachable via a specific address and port that you define in your jiveclientconfiguration.json file. I tried to deploy a tile addon to Azure websites hoping that would work but there is no way to define what port number Azure uses.
Where do you deploy your production Jive addons at and how do you set your configuration file?
Some of Jive documentation could be a bit confusing.
here the main steps I followed:
Sign up for a free account at Nitrous.IO.
Create a new Node.js workspace.
Install the Node SDK within the Nitrous workspace (npm install jive-sdk -g).
Create a new tile, app, or whatever you want to create (e.g. jive-sdk create tile-list).
Update dependencies (npm update).
Get the URI for your new workspace. (You can use the "Preview" menu to get this... e.g. http://fierce-meteor-71-123263.usw1-1.nitrousbox.com/) Update jiveclientconfiguration.json with this URL.
Start your service (node app.js).
Download extension.zip from Nitrous.
AND THEN... upload that extension.zip to the Sandbox and follow the other directions.
I tried this scenario earlier in the week and it worked for me. Let me know if this helps.