Skip to main content

Home/ Larvata/ Group items tagged development

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
張 旭

What Is a Service Mesh? - NGINX - 0 views

www.nginx.com/...what-is-a-service-mesh

docker service networking nginx proxy

shared by 張 旭 on 27 Aug 18 - No Cached
  • The mesh provides service discovery, load balancing, encryption, authentication and authorization, support for the circuit breaker pattern, and other capabilities.
  • The service mesh is usually implemented by providing a proxy instance, called a sidecar, for each service instance
  • the term service is often used for both the instance definitions and the instances themselves.
  • ...5 more annotations...
  • A sidecar proxy is a proxy instance that’s dedicated to a specific service instance.
  • The container management framework keeps a list of instances that are ready to receive requests.
  • The service mesh can encrypt and decrypt requests and responses
  • a service mesh application also includes a monitoring and management layer, called the control plane.
  • Service mesh architectures are not ever likely to be the answer to all application development and delivery problems
張 旭

A Complete Beginner's Guide to Django - Part 1 - 0 views

simpleisbetterthancomplex.com/...rs-guide-to-django-part-1.html

django python web development

shared by 張 旭 on 08 Jul 18 - No Cached
  • are Python functions that receive an HttpRequest object and returns an HttpResponse object. Receive a request as a parameter and returns a response as a result.
  • is a Web application that does something. An app usually is composed of a set of models (database tables), views, templates, tests.
  • One project can be composed of multiple apps, or a single app.
  • ...1 more annotation...
  • this is the file where we handle the request/response cycle of our Web application.
張 旭

Rails API Testing Best Practices - 0 views

matthewlehner.net/rails-api-testing-guidelines

rails api programming development

shared by 張 旭 on 29 Jun 17 - No Cached
  • Writing an API is almost a given with modern web applications
  • A properly designed API should return two things: an HTTP response status-code and the response body.
  • Testing the status-code is necessary
  • ...6 more annotations...
  • testing the response body should just verify that the application is sending the right content.
  • Unauthorized
  • Forbidden
  • Your test should also ensure that any desired business logic gets completed as expected.
  • Request specs provide a thin wrapper around Rails’ integration tests, and are designed to drive behavior through the full stack
  • we’ll be doing json = JSON.parse(response.body) a lot. This should be a helper method.
張 旭

Search and filter Rails models without bloating your controller - Justin Weiss - 0 views

www.justinweiss.com/...thout-bloating-your-controller

rails search development programming database model scope

shared by 張 旭 on 01 Jul 17 - No Cached
  • Rails includes scopes, which can provide you with a lot of what you need for simple searching, filtering, and sorting.
  • scope chaining
  • filtering and searching of your models with one line in the controller and one line in the model.
  • ...2 more annotations...
  • .public_send
  • ClassMethods
張 旭

Four-Phase Test - 0 views

robots.thoughtbot.com/four-phase-test

test programming development

shared by 張 旭 on 20 Jun 17 - No Cached
張 旭

dry-rb - Home - 0 views

dry-rb.org

ruby programming development

shared by 張 旭 on 02 Oct 16 - No Cached
  • crazylion lee on 02 Oct 16
     
    "dry-rb is a collection of next-generation Ruby libraries, each intended to encapsulate a common task"
張 旭

phusion/baseimage-docker - 1 views

github.com/...baseimage-docker

docker ubuntu base system

shared by 張 旭 on 24 Jun 15 - No Cached
    • 張 旭
      張 旭 on 24 Jun 15
       
      原始的 docker 在執行命令時，預設就是將傳入的 COMMAND 當成 PID 1 的程序，執行完畢就結束這個  docker，其他的 daemons 並不會執行，而 baseimage 解決了這個問題。
    • crazylion lee
      crazylion lee on 17 Dec 15
       
      好棒棒
  • docker exec
  • Through SSH
  • ...57 more annotations...
  • docker exec -t -i YOUR-CONTAINER-ID bash -l
  • Login to the container
  • Baseimage-docker only advocates running multiple OS processes inside a single container.
  • Password and challenge-response authentication are disabled by default. Only key authentication is allowed.
  • A tool for running a command as another user
  • The Docker developers advocate the philosophy of running a single logical service per container. A logical service can consist of multiple OS processes.
  • All syslog messages are forwarded to "docker logs".
  • Baseimage-docker advocates running multiple OS processes inside a single container, and a single logical service can consist of multiple OS processes.
  • Baseimage-docker provides tools to encourage running processes as different users
  • sometimes it makes sense to run multiple services in a single container, and sometimes it doesn't.
  • Splitting your logical service into multiple OS processes also makes sense from a security standpoint.
  • using environment variables to pass parameters to containers is very much the "Docker way"
  • Baseimage-docker provides a facility to run a single one-shot command, while solving all of the aforementioned problems
  • the shell script must run the daemon without letting it daemonize/fork it.
  • All executable scripts in /etc/my_init.d, if this directory exists. The scripts are run in lexicographic order.
  • variables will also be passed to all child processes
  • Environment variables on Unix are inherited on a per-process basis
  • there is no good central place for defining environment variables for all applications and services
  • centrally defining environment variables
  • One of the ideas behind Docker is that containers should be stateless, easily restartable, and behave like a black box.
  • a one-shot command in a new container
  • immediately exit after the command exits,
  • However the downside of this approach is that the init system is not started. That is, while invoking COMMAND, important daemons such as cron and syslog are not running. Also, orphaned child processes are not properly reaped, because COMMAND is PID 1.
  • add additional daemons (e.g. your own app) to the image by creating runit entries.
  • Nginx is one such example: it removes all environment variables unless you explicitly instruct it to retain them through the env configuration option.
  • Mechanisms for easily running multiple processes, without violating the Docker philosophy
  • Ubuntu is not designed to be run inside Docker
  • According to the Unix process model, the init process -- PID 1 -- inherits all orphaned child processes and must reap them
  • Syslog-ng seems to be much more stable
  • cron daemon
  • Rotates and compresses logs
  • /sbin/setuser
  • A tool for installing apt packages that automatically cleans up after itself.
  • a single logical service inside a single container
  • A daemon is a program which runs in the background of its system, such as a web server.
  • The shell script must be called run, must be executable, and is to be placed in the directory /etc/service/<NAME>. runsv will switch to the directory and invoke ./run after your container starts.
  • If any script exits with a non-zero exit code, the booting will fail.
  • If your process is started with a shell script, make sure you exec the actual process, otherwise the shell will receive the signal and not your process.
  • any environment variables set with docker run --env or with the ENV command in the Dockerfile, will be picked up by my_init
  • not possible for a child process to change the environment variables of other processes
  • they will not see the environment variables that were originally passed by Docker.
  • We ignore HOME, SHELL, USER and a bunch of other environment variables on purpose, because not ignoring them will break multi-user containers.
  • my_init imports environment variables from the directory /etc/container_environment
  • /etc/container_environment.sh - a dump of the environment variables in Bash format.
  • modify the environment variables in my_init (and therefore the environment variables in all child processes that are spawned after that point in time), by altering the files in /etc/container_environment
  • my_init only activates changes in /etc/container_environment when running startup scripts
  • environment variables don't contain sensitive data, then you can also relax the permissions
  • Syslog messages are forwarded to the console
  • syslog-ng is started separately before the runit supervisor process, and shutdown after runit exits.
  • RUN apt-get update && apt-get upgrade -y -o Dpkg::Options::="--force-confold"
  • /sbin/my_init --skip-startup-files --quiet --
  • By default, no keys are installed, so nobody can login
  • provide a pregenerated, insecure key (PuTTY format)
  • RUN /usr/sbin/enable_insecure_key
  • docker run YOUR_IMAGE /sbin/my_init --enable-insecure-key
  • RUN cat /tmp/your_key.pub >> /root/.ssh/authorized_keys && rm -f /tmp/your_key.pub
  • The default baseimage-docker installs syslog-ng, cron and sshd services during the build process
張 旭

The Twelve-Factor App - 0 views

12factor.net/backing-services

programming application development

shared by 張 旭 on 27 Jan 19 - No Cached
  • A backing service is any service the app consumes over the network as part of its normal operation.
  • A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code.
  • only the resource handle in the config needs to change
  • ...2 more annotations...
  • Each distinct backing service is a resource.
  • Resources can be attached to and detached from deploys at will.
張 旭

The Twelve-Factor App - 0 views

12factor.net/port-binding

development application programming

shared by 張 旭 on 20 Feb 19 - No Cached
  • The twelve-factor app is completely self-contained
  • using dependency declaration to add a webserver library to the app, such as Tornado for Python, Thin for Ruby, or Jetty for Java and other JVM-based languages.
  • the port-binding approach means that one app can become the backing service for another app
張 旭

The Twelve-Factor App - 0 views

12factor.net/disposability

development application programming

shared by 張 旭 on 20 Feb 19 - No Cached
  • they can be started or stopped at a moment’s notice.
  • Processes should strive to minimize startup time
  • Processes shut down gracefully when they receive a SIGTERM signal from the process manager.
  • ...4 more annotations...
  • returning the current job to the work queue
  • all jobs are reentrant, which typically is achieved by wrapping the results in a transaction, or making the operation idempotent
  • Processes should also be robust against sudden death, in the case of a failure in the underlying hardware.
  • a twelve-factor app is architected to handle unexpected, non-graceful terminations
張 旭

The Twelve-Factor App - 0 views

12factor.net/logs

development application programming

shared by 張 旭 on 20 Feb 19 - No Cached
  • Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services.
  • Logs have no fixed beginning or end, but flow continuously as long as the app is operating.
  • each running process writes its event stream, unbuffered, to stdout.
  • ...2 more annotations...
  • long-term archival. These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment.
  • Most significantly, the stream can be sent to a log indexing and analysis system such as Splunk, or a general-purpose data warehousing system such as Hadoop/Hive.
張 旭

The Twelve-Factor App - 1 views

12factor.net/build-release-run

development application programming

shared by 張 旭 on 20 Feb 19 - No Cached
  • separate build and run
  • The build stage is a transform which converts a code repo into an executable bundle known as a build.
  • the build stage fetches vendors dependencies and compiles binaries and assets.
  • ...7 more annotations...
  • The release stage takes the build produced by the build stage and combines it with the deploy’s current config.
  • is ready for immediate execution in the execution environment.
  • The run stage (also known as “runtime”) runs the app in the execution environment
  • strict separation between the build, release, and run stages.
  • the Capistrano deployment tool stores releases in a subdirectory named releases, where the current release is a symlink to the current release directory.
  • Every release should always have a unique release ID
  • Releases are an append-only ledger and a release cannot be mutated once it is created.
張 旭

The Twelve-Factor App - 0 views

12factor.net/processes

development application programming

shared by 張 旭 on 20 Feb 19 - No Cached
  • stateless processes
  • a production deploy of a sophisticated app may use many process types, instantiated into zero or more running processes.
  • Twelve-factor processes are stateless and share-nothing.
  • ...6 more annotations...
  • Any data that needs to persist must be stored in a stateful backing service, typically a database.
  • The memory space or filesystem of the process can be used as a brief, single-transaction cache.
  • wipe out all local (e.g., memory and filesystem) state
  • compiling during the build stage
  • “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process.
  • Sticky sessions are a violation of twelve-factor and should never be used or relied upon
張 旭

The Twelve-Factor App - 0 views

12factor.net/concurrency

development application programming

shared by 張 旭 on 20 Feb 19 - No Cached
  • PHP processes run as child processes of Apache, started on demand as needed by request volume.
  • Java processes take the opposite approach, with the JVM providing one massive uberprocess that reserves a large block of system resources (CPU and memory) on startup, with concurrency managed internally via threads
  • Processes in the twelve-factor app take strong cues from the unix process model for running service daemons.
  • ...3 more annotations...
  • application must also be able to span multiple processes running on multiple physical machines.
  • The array of process types and number of processes of each type is known as the process formation.
  • Twelve-factor app processes should never daemonize or write PID files.
張 旭

The Twelve-Factor App - 0 views

12factor.net/admin-processes

development application programming

shared by 張 旭 on 20 Feb 19 - No Cached
  • The process formation is the array of processes that are used to do the app’s regular business
  • one-off administrative or maintenance tasks for the app
  • One-off admin processes should be run in an identical environment as the regular long-running processes of the app.
  • ...2 more annotations...
  • Admin code must ship with application code to avoid synchronization issues.
  • Twelve-factor strongly favors languages which provide a REPL shell out of the box, and which make it easy to run one-off scripts.
張 旭

Scalable architecture without magic (and how to build it if you're not Google) - DEV Co... - 0 views

dev.to/...ld-it-if-youre-not-google-336a

development architecture system google

shared by 張 旭 on 24 Feb 19 - No Cached
  • Don’t mess up write-first and read-first databases.
  • keep them stateless.
  • you should know how to make a scalable setup on bare metal.
  • ...29 more annotations...
  • Different programming languages are for different tasks.
  • Go or C which are compiled to run on bare metal.
  • To run NodeJS on multiple cores, you have to use something like PM2, but since this you have to keep your code stateless.
  • Python have very rich and sugary syntax that’s great for working with data while keeping your code small and expressive.
  • SQL is almost always slower than NoSQL
  • databases are often read-first or write-first
  • write-first, just like Cassandra.
  • store all of your data to your databases and leave nothing at backend
  • Functional code is stateless by default
  • It’s better to go for stateless right from the very beginning.
  • deliver exactly the same responses for same requests.
  • Sessions? Store them at Redis and allow all of your servers to access it.
  • Only the first user will trigger a data query, and all others will be receiving exactly the same data straight from the RAM
  • never, never cache user input
  • Only the server output should be cached
  • Varnish is a great cache option that works with HTTP responses, so it may work with any backend.
  • a rate limiter – if there’s not enough time have passed since last request, the ongoing request will be denied.
  • different requests blasting every 10ms can bring your server down
  • Just set up entry relations and allow your database to calculate external keys for you
  • the query planner will always be faster than your backend.
  • Backend should have different responsibilities: hashing, building web pages from data and templates, managing sessions and so on.
  • For anything related to data management or data models, move it to your database as procedures or queries.
  • a distributed database.
  • your code has to be stateless
  • Move anything related to the data to the database.
  • For load-balancing a database, go for cluster.
  • DB is balancing requests, as well as your backend.
  • Users from different continents are separated with DNS.
  • Keep is scalable, keep is stateless.
  • 張 旭 on 24 Feb 19
     
    "Don't mess up write-first and read-first databases."
張 旭

The Twelve-Factor App - 0 views

12factor.net/codebase

development programming system software

shared by 張 旭 on 01 Jan 19 - No Cached
  • A copy of the revision tracking database is known as a code repository, often shortened to code repo or just repo.
  • always a one-to-one correlation between the codebase and the app
  • If there are multiple codebases, it’s not an app – it’s a distributed system.
  • ...4 more annotations...
  • Each component in a distributed system is an app
  • only one codebase per app, but there will be many deploys of the app.
  • A deploy is a running instance of the app.
  • The codebase is the same across all deploys, although different versions may be active in each deploy.
  • 張 旭 on 01 Jan 19
     
    "A copy of the revision tracking database is known as a code repository, often shortened to code repo or just repo."
« First ‹ Previous 141 - 160 of 192 Next › Last »
Showing 20▼ items per page