try setting up stack myself instead of using digital ocean’s pre-setup droplets
more expertise gained
more familiarity with configuration?
since I’m not using Wordpress as a monolithic CMS, I don’t need some of the standard components, e.g. apache
2.
have separate servers for test and prod of kusamochi
😅 : d13
practices online don’t seem to attempt to host test and prod on one server
confusing between configuration through Wordpress and configuration through Apache, with Nginx above..?
if I rely on a database, I probably want a separate prod database and a separate test database. hosting 2 virtual domains, 2 databases on one server starts to get confusing.
if I set up a script to provision the servers, then I can set up new test and prod servers with ease(all the same setup, I suppose); double-tasking for scaling needs. but if I combine test and prod on one server, the provisioning script will make a combined test&prod with each deploy
3.
having staging environment go with subdomain or actual domain - undecided
use Digital Ocean droplets instead of AWS EC2 instances
about half the price of EC2 instances, according to rates
more comfortable starting with blank slate rather than working from pre-setup instances o_O
7.
use Digital Ocean object storage for at least some storage needs
free through Oct.
not sure yet what sort of cost hosting my own dbs(whether relational or nonrelational) will pose
8.
use lowest tier for kusamochi droplets
assuming that this tier is still good for a website with almost zero traffic. lol
can change in future if necessary
9.
use two droplets for kusamochi to start with(1 stage, 1 prod)
😅 : d13
although not ideal to have front end and back end on same server, necessarily, saves $$
can change in future if necessary
10.
use same ssh pub for both droplets
saves me a little bit of time :/
supposedly a security issue but I think if someone gets ahold of my key pair for one, they’ll have access to the other ; not going to use different security measures for different key pairs.
11.
use duplicated commits(git cherry pick) and multiple pushes to push the same changes to two destinations, rather than a simultaneous push to two destinations(using multiple git remotes)
my sense of how git commits work
worried that if I git commit the same commit to two repos, both repos will end up in same state, rather than keep different states with addition of same change.
8/04/2017
12.
publish changes to mugwort’s ssh folder only to private repo
might be nice to show configurations to .ssh file, but it reveals what access is available from this host.
other contents(keys) are absolutely sensitive anyway, and I don’t want to open myself up to mistakes by occasionally pushing some contents to public repo
13.
run app as microservices in docker
if I use containers, I can maybe test the app on localhost, or have stage and prod on one droplet, saving me money(ty Steven for this pt)
gives me the isolation I want between microservices
use docker swarm for container mgmt, if needed
seems simpler than using kubernetes, for now
beginner level tutorials for this
use Ansible for both provisioning docker and code deployment of compose files, if necessary?
seems to do both tasks, as opposed to needing to pair Chef and Puppet otherwise
easy tutorial to demonstrate?
not sure if Docker swarm cmds eliminate some need for code pushing…
8/07/2017
16.
don’t use nodemon for the time being
currently causes issues for running barebones express app in remote swarm
might be useful later but would take time to untangle how to get it running only in dev; or working in prod
17.
push images for different services to the same repo
push images for different services to separate repos
haven’t seen any real examples of this and might get messy, but makes sense to me according to‘repo’ terminology
will be pushing to same image name for‘latest’ ver of each service image
can change later…
never mind… going by the default‘latest’ tag, the tags are meant to distinguish between different versions of one image rather than images for different services
8/08/2017
18.
use ansible container at least to build my images..?
it’s nice that I can just use other people’s roles, and not write custom Dockerfiles. then again I could probably use people’s images instead of writing my own Dockerfiles to set up wordpress, etc., too?
push images for different services to the same repohaven’t seen any real examples of this and might get messy, but makes sense to me according to‘repo’terminologywill be pushing to same image name for‘latest’ver of each service imagecan change later…use ansible container at least to build my images..?