Build on EC2

fedoraman87422 years ago

4

• 

  trinutz2 years ago

  Like any other piece of code, have you ever deployed anything on AWS? it would be easier to deploy on ECS/Fargate, assuming you know about Docker.

  
  

  There is a 1000s way to deploy code online, start from an Hello World docker project on ECS, you'll see more clearly after that.

• 

  denolfe

  2 years ago

  Take a look here if you haven't already:

  https://payloadcms.com/docs/production/deployment
  
  

  The TLDR is that you'll need to install dependencies, compile your code, build the payload admin panel, then put it all in one place to run.

  
  
  

  If you're using one of the create-payload-app templates, you should be able to follow the steps in the reference Dockerfile from that link:

  
  
  

  yarn install
  yarn build

  
  

  Then copy package.json, node_modules, dist/, and build to your destination

• 

  ceibuulast year

  I'm also intrigued on this front, sorry if this is digging back up an old topic/issue. I've managed to get a couple of apps up and running within Docker on AWS, however there are some unique challenges that have come up when trying to implement the same with Payload - or any other database connected app for that matter. In particular, the main hurdle I have come across is how to configure a multi-container instance using compose where the database along with payload and a next frontend are deployed simultaneously. Running the code in development works as expected - Mongo is setup first and then payload and next follow suit. However when running a production build using the dockerfile outlined in the docs

  https://payloadcms.com/docs/production/deployment#docker

  (along with accompanying env file), an error is thrown on build of payload stating:

  
  
  

  Error cannot connect to mongoDB. Details: getaddrinfo ENOTFOUND mongo

  
  
  

  As far as I can tell from this message, the issue is that mongo is:

  
  

  A) Either not running

  
  

  B) Is running, but payload has no context for it's whereabouts.

  
  
  

  My compose file follows a very similar structure to that outlined in the example linked above, the only difference being the payload instance is trying to build instead of running dev.

  
  
  

  Curious as to how others have handled / managed their database and associated connections when dockerizing the entire stack. Is the preferred method to have an entirely different docker file / "project" to manage the database so that it stands alone from the rest of the app and therefore is "always running?"

  
  
  

  Keen to hear back and thanks in advance!

  
  
  

  EDITED:

  
  

  It would appear, after a bit more reading this is indeed intended by the payload team, that is, if I am understanding their definition of "communicating locally" in the description on MongoDB here:

  
  https://payloadcms.com/docs/production/deployment#managing-mongodb-yourself
• 

  lzyaclast year

  ooh yes I would love to see an answer for this

  
  
  

  I've only got development working currently as well