I think the "generic" term is "multi-tier architecture" or "n-tier architecture".

I have not deployed a Laravel Octane environment before.....but looking at the docs I see this: "Laravel Octane supercharges your application's performance by serving your application using high-powered application servers, including FrankenPHP, Open Swoole, Swoole, and RoadRunner. Octane boots your application once, keeps it in memory, and then feeds it requests at supersonic speeds." When I visited FrankenPHP docs, it looks like the preferred way to deploy is to run this in a container. My guess is that they will have their container already "highly optimized"....so you probably don't have to do much inside their container. Interesting technology....maybe someday I will be able to take a deeper look. Thanks for watching!

@@thetechnologysandbox Thank you for your reply. Love the whole series and looking forward for more content from you!

I will be posting at least one video in the near future on creating a CI/CD pipeline that automates this process. It will be part of the #AWS series but the concepts will be applicable to DO. First, I think you will need to decide between: 1. Deploying Code - In this case, you setup your Docker production environment. To deploy a new release you trigger a "git pull" in the services that leverage the code (nginx, horizon, artisan, ...). 2. Deploying Containers - In this case, you will need to create a CI/CD pipeline that creates a new docker image(s) and deploys those to production. You probably want to use some orchestration tool (swarm, kubernetes, ...) to aid in the provisioning / teardown of these updates. One change you will want to think about is you will probably want to have a "prod" and a "dev" version of the environment. As an example, the environment the starter kit creates is a "full stack" that includes nginx, php, mysql, redis, ...etc. In the "prod" environment, I would lean towards creating an environment where the data storage services (mysql, redis,...) are deployed as separate services (e.g., Amazon RDS, Amazon ElastiCache). So my "prod" docker compose file will not need to create those services / images. Hope those are my initial thoughts...hope that helps!

I thank you for your reply. I am subscribed so I await your next video. I am a bit new to these concepts and have played around with CI/CD. Going to keep reading and trying to understand. Thanky you.

That is a great question and I plan on covering improvements to the CI/CD pipeline that will allow us to push new code. Right now we have “containerized” our code by manually creating an AMI containing the current version. Obviously this is not ideal and I the improvements in future videos will be discussing some options. There are a number of solutions, but I will probably end up building a docker image in the CI/CD pipeline and deploying that image either using ECS or EKS. Hopefully that helps. More details in upcoming videos….

@@thetechnologysandbox Thank you , looking forward to your videos. Best regards

You're welcome

You're welcome!

Hopefully you got past this issue. Sounds like either "laravel_demo" is not the user you used or the ".ssh" directory was not created.

I do have a Github repo (github.com/rcravens/devops-laravel/tree/master) with the provisioning and deployment code. You can find the ubuntu provisioning scripts in the "provision" directory. Hope that helps.

Sorry for the delay. There is a github repo here: github.com/rcravens/devops-laravel. This contains most of the command lines that I manually entered. You can find the "ubuntu provisioning" scripts in the "provision" directory. In the "deploy" directory you will find the scripts to deploy an application. BTW, these deployment scripts are covered in detail in the 4 "Infrastructure As Code" videos. The link to the first one is here: kzfaq.info/get/bejne/bd5_o9uhybLHln0.html.

Great to hear!

My bad....here is the repo: github.com/rcravens/laravel_demo. Thanks for watching!

That is scheduled for Tuesday. Glad you are enjoying.

Thanks for watching…I appreciate it! This is a great question. I don’t think it is a either Docker or the provisioning script. When I created the Docker Starter Kit for Laravel (github.com/rcravens/docker_starter_for_laravel) the provisioning code is in the dockerfile for PHP. when you compare these you will find a lot of the same code (e.g., using apt to install PHP…). To write things once and use everywhere, I could imagine the dockerfile git cloning the dev ops repo and running the provisioning script inside the container. That would allow you to maintain a “one code base for ubuntu provisioning”. On the other hand, the provisioning completed in this video is a “monolithic” application where in the docker starter kit, i split that up into multiple services….PHP, nginx, mysql, redis all had their own docker service. That is where we will end up in this “deploy laravel to AWS” series as we start to explore the best options for scaling (coming soon). So eventually, the infrastructure will better match what is in the Docker starter kit. Hope that helps!

The key is to provide some indication of the uncertainty in the estimate. I don't know if there is a "one right answer" on how to do this. Here are a few methods and I am sure there are others: - For slide decks showing project status, provide an appropriate "disclaimer" that indicates the level of uncertainty in the estimates. I could imaging that for timelines out past 6 months the disclaimer is different that if the timeline is discussing tasks completing in the next 1 or 2 sprints. - If you are using using Excel for presenting status, the you could use a formula to automatically color code feature based on their due date. The colors don't have to be "scary" like red for anything completing 6 months or later, but can be subtle as long as "what the color codes mean" is communicated. As mentioned, the goal is to provide some indication of the uncertainty and not to cause a panic....so choose how you present this information wisely ;-))

Thanks for watching!

Wow! Bob, that AI detector is really good. The way you prompted and enhanced the prompts to make the results personalized and humanlike is exceptional. Very impressive 👍

My bad. I usually remember but forgot. Sorry

That is true. The DNS query results typically are cached for the TTL time period. When I was testing the Nginx / Docker configuration it appeared that the default TTL was set to 600s, but when I dynamically scaled the application the new IP addresses were being served up right away. This makes sense as on the resolver line in the nginx conf file there is a "valid=5s;". Thanks for starting this discussion!

Here is a great article on how Nginx handles DNS resolution for a few configuration: www.nginx.com/blog/dns-service-discovery-nginx-plus/.

Glad you like them!

I think that periodically uploading a JPEG is definitely doable. I would think that streaming should also be possible, but I am a bit more skeptical if this hardware could do that via the SIM module. Probably the best design would be having a "normal" picture rate of every 5-10 minutes, but dynamically increasing that rate if certain events occurred (e.g., GPS position change, or motion detected since the last photo...etc).