I recently deployed my GitHub project in aws using Amazon Linux 2 AMI.
I installed npm, MongoDB, node and cloned the Github repo into the new instance that I created by sshing into it.
I am running the server with the forever package of npm.
Now, I made some changes in the code and pushed it to my Github repo but it's not being reflected in my project when I try to access it from outside.
So, how to redeploy it so that I see my changes when I access it from outside world?
I found this video which shows how to redeploy but it's not feasible in my case to do it.
Now, I made some changes in the code and pushed it to my Github repo but it's not being reflected in my project
Pushing to GitHub is one step.
But you still need to ssh to your execution environment (aws), and pull from GitHub in order to get the latest.
Then your npm application would have a chance to display your changes.
As an alternative to forever restart, you also can use PM2, as recommended here.
Another option would be to add a GitHub Action, like one of the deployment actions, in order to automate that step.
AWS proposes dedicated GitHub actions.
Full example: "Github Actions for web apps" from Luke Boyle.
From what I'm able to figure out you need to do the following steps:
Do a git pull after logging into your server via ssh.
cd toTheFolder where your git repo is located
git pull origin yourBranchName
forever restart or forever restartall should restart your server and your changes should reflect there.
And as VonC suggested you should go for PM2 instead but for now you can continue with forever. PM2 is very similar to forever but with a lot more features available.
Related
I'm trying to send a request in my getStaticProps function to my backend api from another docker container. However, even though the api url is written correctly, the static page still is not created. This is because for the static page to be built, the backend should be up already, and because it is build-time the other container is not up yet and waits for the build to be finished and the build can not be finished without the backend.
So what's the solution to this approach? I tried setting the depends_on value to my other container, still doesn't work. what solution would you suggest?
There are 2 solutions I can think of.
Apparently, the Next.js build fails because the service it is querying is not running. Thus why not build and start the service it depends on explicitly and build the rest like this.
docker-compose build some_services
docker-compose up -d some_services
docker-compose build the_rest
This way the Next.js app will be able to make the request. Please keep in mind that You still need to configure the ports and networks correctly. Pretty sure this will resolve the issue.
A more 'fancy' solution would be using build-time networks which are added in the later versions, 3.4+ if I am not mistaken.
docker-compose.yml
build:
context: ./service_directory
network: some_network
For more details please see Docker-compose network
Running a new service that depends whether another service is up or not is a tricky part of docker orchestration. Keep in mind that even with Healthcheck, it doesn't guarantee you database is ready before the next stage. depends_on is not going to be really helpful, because it just determine the order of running service. docker documentation:
depends_on does not wait for db and redis to be “ready” before starting web - only until they have been started. What docker doc suggests is to write a wait-for-it script or [wait-for][2] and run it after or before depends-on. For example:
build: next_service
command: sh -c './wait-for db:5432 -- npm start'
depends_on:
- db
And of course, you explicitly run separate docker-compose command but that loses the point of docker orchestration.
I've build a static react website using create-react-app and deployed it in netlify using git and github. Turns out, I've to make a small change in my website now. What should I do so that the changes reflect on the already deployed site. I committed changes in github but the change is not showing in the live deployed url.
You can commit a new version of your website easily.
after editing or changing the file in you need to use
git add --all
and commit the file by the following command.
git commit -m"you can add you commit message here'
after these steps, you can add the remote by the following command.
git remote add remote-name https://repo-link-here..
if you already added remote you can skip the step just top of this sentence.
after that, you can push the committed branch by the following command
git push remote-name branch
the default name of remote is origin
the default branch is master
you can also use the default names also.
I am writing a service with node.js, and depending on whether a file in my gitlab project has been recently updated or not, the way the service works will change. So how can I tell if the content of a file in my gitlab project has changed or not on the node.js service side? Is there a Gitlab API service for this?
Gitlab does offer a robust API but could you not just run a git fetch and diff:
git fetch origin master
git diff origin/master:./ --compact-summary
That will list any files that have changed compared to your local. If you'd like to access that from Node you could put it in a shell script, run it as a spawned child_process and parse the stdout.
This method depends on your service checking for changes manually, if instead you want your service to be alerted when a change happens at any time you may want to look into webhooks: https://docs.gitlab.com/ee/user/project/integrations/webhooks.html
you can monitor (with a crontab) the project's commits or with webhooks (like #Dave said) and after that get commit diff info with gitlab commit api to see if your file was modified
I have a simple CLI application written in Javascript using Node that is for internal use by a small team. It runs in the Linux terminal as a CLI app. The app consists of a single ".js" file and requires a few Node packages. The problem I face now is how to deploy it to our internal team using a simple method that fits with our routine process of keeping end user computers updated.
Our app needs to be installed once per workstation / laptop and to be available to all users on that computer. Any user should be able to open a terminal and enter the command to run the app.
It seems a lot of people have discussed using Javascript for shell programming, but this issue of deploying the completed app is not widely discussed. I have not found anything on the topic. So far I have been recommended solutions that are appropriate for either development environments or web servers.
This app is not a web app and it is not deployed on a server. It needs to run offline. I am also not asking about developing or maintaining the app on a development workstation.
The installation process should ideally be as about simple as installing a shell script in /usr/local/bin and setting permissions so all permitted users on a computer can run it. We are looking for an installation method like this:
copy the Javascript file only once to each computer (to a location on the $PATH) and make sure the Node packages are available globally on that computer.
I specifically want to avoid having to do an npm install for each user account on each computer.
I also want to avoid having to update Node packages for each user account on each computer.
A developer will keep the app updated so it is always compatible with the latest version of the Node packages, and all computers it is deployed on will always have the latest versions of those packages installed.
One specific problem I encountered is discussed here, but the answers assume a different set of requirements (such as the need for "multiple applications running on different package versions").
For those requirements, if the actual problem is solving the EACCESS error (you should edit the question to include that information), then you should look at the permissions of all directories, and make sure that the user account that manages node packages on each computer has correct permissions.
One way to do that is to give /usr/local a special group, set the sticky bit with chmod (see man chmod), and use chgrp -R on the existing tree.
Then make the installing account a member of that group, and don't use sudo for npm install -g.
(Never using sudo for installations into /usr/local has the additional advantage that you can't accidentally install something somewhere else, for example because you didn't set paths in this local package source correctly.)
We are using these two approaches for similar deployments:
the programs live on a specific network mount. All users can run the same package from there. The developer only updates this package. No copying to local machines.
we use a simple deployment script which runs on all machines on logon. It pushes and copies the latest version to the local machine.
I'm learning Node and Git and I have a Heroku app that is reading and writing to a local file on the server (a very simple JSON database).
If I add the file to my gitignore locally, it disappears from my Heroku app and causes the app to error. But if I don't add it to my gitignore, it overwrites the latest version (on the server) with an old one I have locally.
Obviously the issue is because the changes on the server file aren't being committed. However, I don't know how to do that remotely, or if it's even possible. I can run heroku git:clone locally, but I can't run heroku:git add.
How do I handle this?
Generally, you should not commit a file that will be modified by the server.
It seems not a good idea because, as you said, this file will be overwrited by next push.
Usually you do not want to commit from your deployment branch, so it is not a good idea either to use git from server (and I doubt you can with Heroku).
Instead you could make your app check if the file exists and if not create that file on server.
That will work in a dedicated server you manage yourself, but Heroku doesn't work the same. Each push you make to your Heroku repository will in fact bundle your application before launching it on a dyno, and this process overwrite all the file, including your database JSON file, which will be no more persistent.
So I think you have no choice than switch to another storage method, for exemple subscribe a free Heroku postgreSQL plan or another database you prefer.